On Sun, 09 Sep 2001 18:33:11 -0700
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> To me, they both look like persistent hashes. Apache::Session assumes
> you will be storing a serialized hash in each hash value, and that it
> will generate IDs for keys if you don't supply one, but otherwise
> they're about the same.
You're right. The (slight) difference you mention is all that this
module does.
> > Cache::Cache ensures file-based atomic update. But IMHO
> > it's not enough for Apache::Session's session transactions, which
> > should be done exclusively. Session data would get logically
> > inconsistent when there are multiple concurrent requests with same
> > one session id.
>
> Apache::Session uses shared read locks, so I think you can still have
> problems there. It doesn't gurantee an atomic read-change-modify.
Forgot to mention 'Transaction => 1' argument. Thanks for fixing
me.
In fact, the storage model I heavily use is A::S::Store::MySQL,
whick locking scheme is *always* exclusive.
Now, without Transaction => 1 argument, there is no need to use
locking scheme for preventing corrupted data update, because
Cache::Cache already ensures it, as you wrote.
Should I make Apache::Session::Lock::Cache, using Semaphore or
File only in case of Transacton mode?
package Apache::Session::Lock::Cache;
use strict;
use base qw(Apaache::Session::Lock::Semaphore);
sub acquire_read_lock { 1 }
sub release_read_lock { 1 }
sub acquire_write_lock {
my($self, $session) = @_;
if ($session->{args}->{Transaction}) {
$self->SUPER::acquire_write_lock($session);
}
}
# blah, blah
--
Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
