What is best ApacheSessionX locking mechanism

[Scott Chapman <sc...@mischko.com>]

I'm presented with a BUNCH of locking mechanisms when installing 
Apache::SessionX.  I'd like to know a couple things that will be helpful!

1) What exactly are we locking with Apache::SessionX?  As I understand it, 
sessions are handled via cookies so we are not actually locking anything but 
creating a unique ID for the cookies to hold and then we match that up with a 
session store on the server.

2) Which of the available methods for locking is best (most reliable vs. least 
processor intensive)?

3) Clearly, we can't use the Null lock here right?

TIA,
Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org

Re: What is best ApacheSessionX locking mechanism

[Angus Lees <gu...@switchonline.com.au>]

At Wed, 5 Jun 2002 12:31:45 -0700, Scott Chapman wrote:
> 1) What exactly are we locking with Apache::SessionX?  As I
> understand it, sessions are handled via cookies so we are not
> actually locking anything but creating a unique ID for the cookies
> to hold and then we match that up with a session store on the
> server.

need locking to ensure:

1) unique session ids (the number that gets stored in the cookie)

2) session data (stored on the server) is not corrupted by reading it
while its still being written (for example)

> 2) Which of the available methods for locking is best (most reliable
> vs. least processor intensive)?

depends on your setup (what session store are you using? do you have
multiple web servers?)

file locking and storage is probably the most fool-proof to setup, is
fairly easy to look at and understand, but is relatively slow. its
good for a debugging setup.

any of the database storage methods are good since they usually scale
very well, will work from multiple web server machines (all pointing
back to the same database), but require more setup (and are more
difficult to backup, etc).

databases that do transactions essentially do implicit locking, so
they need no further help (use Null locker). MySQL can either use
mysql's table locking (very coarse, which means lots of lock
contention - not good) or SysVSemaphore locking (os-provided shared
memory semaphores - fast, but only work within the one machine) if
there is only one web server.

basically, choose your session store first. the locking method will
follow from that, your OS and whether you have >1 web server.

> 3) Clearly, we can't use the Null lock here right?

you can in cases where there is only ever one apache process accessing
the store at a time (apparently apache is only a single process/thread
on win32), or where the session store works in a way that guarantees
atomic actions anyway (like postgreSQL, which uses transactions).

-- 
 - Gus

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org