Re: RFC: Apache::Session::CacheAny
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]>
Re: RFC: Apache::Session::CacheAny
Tatsuhiko Miyagawa wrote: > Cache::Cache is a cache interface for any key-value pairs with > optioinal automatic expire & purge. > > Apache::Session is a framework for persisntent hash data with > unique identifier and automatic serialiization/deserialization for > hash. 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. > Why not combine these two? That's all what this module does. Okay. Just wondered if I was missing something. > 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. - Perrin
Re: RFC: Apache::Session::CacheAny
On Sun, 09 Sep 2001 15:24:14 -0700 Perrin Harkins <[EMAIL PROTECTED]> wrote: > > Announcing the Adapter module which provides a way to use > > Cache::Cache subclasses as Apache::Session storage implementation. > > Hmmm... > > Don't take this the wrong way, but what's the purpose of this? To glue Cache::Cache with Apache::Session. That's all :-) > Apache::Session does very little beyond what Cache::Cache does. In > fact, the only things I can think of are the tied interface, which is > slower than methods and often confuses people who make updates deep > within the structure that don't trigger a save, and the ID generation, > which is really just a stub and needs to be replaced for any serious > project. Cache::Cache is a cache interface for any key-value pairs with optioinal automatic expire & purge. Apache::Session is a framework for persisntent hash data with unique identifier and automatic serialiization/deserialization for hash. Why not combine these two? That's all what this module does. > Also, why bother with Apache::Session::Lock::Semaphore at all? > Cache::Cache already provides atomic updates. You should be able to use > NullLocker with the same level of safety. 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. Off course, you can change that to adopt A::S::Lock::Null with A::S::Flex. -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Re: RFC: Apache::Session::CacheAny
princepawn wrote: > Above and beyond the efficiency issues you discuss above, could you > comment on what Apache::Session would need to be useful in a serious > project? I was commenting specifically on the ID generation. The algorithm supplied does not guarantee unique IDs, especially when you have a cluster of machines. The design of Apache::Session makes it possible to drop in your own replacement for ID generation, which is what you should do if you're building a large-scale production system. Last time I needed to deal with this I used mod_unique_id as my starting point, which does generate unique IDs across a cluster. - Perrin
Re: RFC: Apache::Session::CacheAny
Perrin Harkins writes: > Tatsuhiko Miyagawa wrote: > > > > Announcing the Adapter module which provides a way to use > > Cache::Cache subclasses as Apache::Session storage implementation. > > Hmmm... > > Apache::Session does very little beyond what Cache::Cache does. In > fact, the only things I can think of are the tied interface, which is > slower than methods and often confuses people who make updates deep > within the structure that don't trigger a save, and the ID generation, > which is really just a stub and needs to be replaced for any serious > project. > [ preface: if there were a [EMAIL PROTECTED] list, I think this discussion would be better received there. can someone make such a list? ] Above and beyond the efficiency issues you discuss above, could you comment on what Apache::Session would need to be useful in a serious project? I have found it very useful in conjunction with CGI::Cookie to maintain state between forms. I mean, as far as I can see, it does one job and does it well with no perceived shortcomings in my eyes. But evidently something in your experiences leads you to other conclusions. And I would like to hear about this.
Re: RFC: Apache::Session::CacheAny
Tatsuhiko Miyagawa wrote: > > Announcing the Adapter module which provides a way to use > Cache::Cache subclasses as Apache::Session storage implementation. Hmmm... Don't take this the wrong way, but what's the purpose of this? Apache::Session does very little beyond what Cache::Cache does. In fact, the only things I can think of are the tied interface, which is slower than methods and often confuses people who make updates deep within the structure that don't trigger a save, and the ID generation, which is really just a stub and needs to be replaced for any serious project. Also, why bother with Apache::Session::Lock::Semaphore at all? Cache::Cache already provides atomic updates. You should be able to use NullLocker with the same level of safety. - Perrin