in reply to Need a workaround: Class variables with MLDBM::Sync

Just store the tied hash inside your object: $calendar->{'data'}. That way you have a separate MLDBM::Sync instance for each calendar object.
  • Comment on Re: Need a workaround: Class variables with MLDBM::Sync

Replies are listed 'Best First'.
Re: Re: Need a workaround: Class variables with MLDBM::Sync
by relax99 (Monk) on Oct 11, 2002 at 19:22 UTC
    Thank you! I have no idea why I didn't think about it before... Now it does seem like an obvious solution. I still didn't get it to work though. I did exactly what you suggested, but now I get this error: (I'm using Storable for serializing data in MLDBM) Can't store CODE items at blib\lib\Storable.pm (autosplit into blib\lib\auto\Storable\_freeze.al) line 264, at C:/Perl/site/lib/MLDBM/Serializer/Storable.pm line 20
      I can't tell you what's going on without seeing your code. Make sure you are only tie-ing the data, not the whole calendar object.

        What happens is Storable can not convert Perl code, which is what this MLDBM::Sync lock object is, into something it can store on disk. I haven't resolved the issue yet. I'm trying to use Data::Dumper, since it can work with Perl code, or, more precisely, it stores objects by converting them to Perl code.

      Perhaps you're running into the same issue that was being addressed over here. (or related anyway). The jist is you should see about upgrading your Storable and maybe perl itself.

      __SIG__ printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B:: +svref_2object(sub{})->OUTSIDE