RFC: Apache::Session::CacheAny
Announcing the Adapter module which provides a way to use
Cache::Cache subclasses as Apache::Session storage implementation.
http://bulknews.net/lib/archives/Apache-Session-CacheAny-0.01.readme
http://bulknews.net/lib/archives/Apache-Session-CacheAny-0.01.tar.gz
Any suggestions are welcome. Thanks.
--
NAME
Apache::Session::CacheAny - use Cache::* for Apache::Session storage
SYNOPSIS
use Apache::Session::CacheAny;
tie %session, 'Apache::Session::CacheAny', $sid, {
CacheImpl = 'Cache::FileCache',
};
tie %size_aware_session, 'Apache::Session::CacheAny', $sid, {
CacheImpl= 'Cache::SizeAwareFileCache',
Namespace= 'apache-session-cacheany',
DefaultExpiresIn = '2 hours',
AutoPurgeOnGet = 0,
AutoPurgeOnSet = 1,
MaxSize = 10_000,
};
DESCRIPTION
Apache::Session::CacheAny is a bridge between Apache::Session and
Cache::Cache. This module provides a way to use Cache::Cache subclasses
as Apache::Session storage implementation.
ARGUMENTS
You must specify class name of Cache::Cache implementation (like
Cache::SharedMemoryCache) in arguments to the constructor. See the
Apache::Session::Store::CacheAny manpage for details about other
optional arguments.
NOTE
Apache::Session::CacheAny uses Apache::Session::Lock::Semaphore as its
locking scheme. You can use Apache::Session::Flex to change that.
AUTHOR
Tatsuhiko Miyagawa [EMAIL PROTECTED]
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
SEE ALSO
the Apache::Session manpage, the Cache::Cache manpage
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
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
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
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
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
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 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]
