Re^3: Locking and synchronisation within tied hashes

None so long as everyone's just reading. If anyone wants to write and tries to get an exclusive lock, they'll have to wait for everyone to finish reading and untie, but that's the point of the excercise: it guarantees that you can never end up writing back out of date data. Of course you'll have to tell your users that they need to untie and forget what they've read as soon as possible, if many processes are to be simultaneously writing to that same database.

Makeshifts last the longest.

Comment on Re^3: Locking and synchronisation within tied hashes

Replies are listed 'Best First'.
Re: Re^3: Locking and synchronisation within tied hashes by rob_au (Abbot) on Sep 08, 2002 at 13:35 UTC
If anyone wants to write and tries to get an exclusive lock, they'll have to wait for everyone to finish reading and untie, but that's the point of the excercise: it guarantees that you can never end up writing back out of date data. Of course you'll have to tell your users that they need to untie and forget what they've read as soon as possible, if many processes are to be simultaneously writing to that same database. Hrmmm, that makes be feel a little uncomfortable - This functional requirement sounds very much like the behaviour of Apache::Session which was, in part, why I started work on this module. I am taking a closer look at MLDBM::Sync as suggested by perrin in this post, but would look to expand upon the relatively fixed framework on this module.	[reply]
Re^5: Locking and synchronisation within tied hashes by Aristotle (Chancellor) on Sep 08, 2002 at 13:47 UTC
If that makes you uncomfortable, you need record-level locking which almost invariably means using a real database. Maybe Tie::DBI is worth a look? Makeshifts last the longest.	[reply]