On Sat, 2004-03-20 at 14:41, Chris Ochs wrote:
> Now the problem is that when the application dies
> unexpectedly, the session locking leaves a lock on the session file.

Which Apache::Session subclass are you using?  With some of them (i.e.
the database-backed ones) you don't really need to bother with the extra
locking.

> since some of the methods in my modules are called from the template toolkit
> via callbacks, it's really difficult to make sure those methods have access
> to the session variable without using global variables (making the session
> variable an argument to the template page functions is not an option).

Why is that?  You may run into more trouble later on if you have
designed things in a way that prevents you from passing data to Template
Toolkit.

There are a couple of pretty established ways of providing universal
access to an object.  One way is to take advantage of mod_perl and store
things you need universal access to in $r->pnotes().  Anything in
pnotes() is request-scoped, so it will be destroyed automatically at the
end of the request even if your code dies.  You can always access it
like this:

my $r = Apache->request();
my $thing = $r->pnotes('thing');

The other way to do it is to make a singleton class or a simple accessor
function that caches the object.  You may still want to use pnotes() to
store it internally, for safety.  (I've had better luck with that than
with cleanup handlers and globals.)  Here's an example:

sub get_session {
    my $r = Apache->request();
    my $session = $r->pnotes('session');
    if ( !$session ) {
        $session = fetch_the_session();
        $r->pnotes('session') = $session;
    }
    return $session;
}

You can still ruin any approach involving Apache::Session by having some
code that uses the session and fails to let it go out of scope, either
because it gets put into a global or stuck in a closure.  However, that
would break the approach you're using now as well, so if it's currently
working for you then you can assume your code doesn't have these
problems.

- Perrin


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Reply via email to