tied hashes frustration

[Chris Ochs <ch...@paymentonline.net>]

I use apache::session in my application which runs as a handler, and the
session variables are needed by just about every module in the application
(14 modules in all).  Now the problem is that when the application dies
unexpectedly, the session locking leaves a lock on the session file.

I have had the session as a global package variable which I export to other
packages that need to access it, which is the root of my problem.  However
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).

Well now what I have is the session variable created by my session module
and it is my scoped.  The module passes back a copy and a reference of the
session hash to my main module. The main module exports the copy of the hash
(but not the reference) globally and at the end of the application execution
I have a cleanup handler that copies the copied hash back to the real
session hash via the reference and then makes sure the reference is
undefined.  Now this does work, the session goes out of scope completely
even if there is a 500 server error and apache::session correctly runs it's
DESTROY method which cleans up the lock file.  It seems like a huge hack to
me though.

Does anyone know of a way to make a copy of a tied hash that is still tied
to the original hash?  And also have it so that the tied copy goes out of
scope when the original hash goes out of scope?  I dont' think this is
possible but thought I would ask.

Chris



-- 
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

Re: tied hashes frustration

[Perrin Harkins <pe...@elem.com>]

On Mon, 2004-03-22 at 13:04, Chris Ochs wrote:
> Rather than passing stuff around in globals or via pnotes, I was thinking
> about making a request object and then using an all OO structure.  Modules
> that have functions that are called via callbacks could have a new() method
> that is called before the template processing, and the new method would be
> passed the request object so it can setup all the variables it needs for the
> other methods that are accessed via callbacks at a later time.
> 
> Does this sound like a good way to go?

It's pretty hard to say without knowing a lot more about your
application's design.  Passing data about the current request around in
an object is a very common design (used by apache itself), so you
shouldn't be too concerned about that.  Just make sure you don't need to
keep a copy of this object anywhere that won't automatically go out of
scope at the end of the current request.

I tend to prefer setting things up as a pipeline over using callbacks
from a view, but it depends greatly on the nature of the application.

- 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

Re: tied hashes frustration

[Chris Ochs <ch...@paymentonline.net>]

Thinking about this a bit more I wanted to run my ideas past the list for
feedback.

First of all, the application is more or less an application server, with
the feature set being heavily on ecommerce functions (shopping cart, payment
processing, file/user/group security, etc..).  The server accepts incoming
requests, passes them off to various internal handlers based on what the
request was, and displays the results either through the template toolkit,
or through some other custom modules if the response is not html.

Rather than passing stuff around in globals or via pnotes, I was thinking
about making a request object and then using an all OO structure.  Modules
that have functions that are called via callbacks could have a new() method
that is called before the template processing, and the new method would be
passed the request object so it can setup all the variables it needs for the
other methods that are accessed via callbacks at a later time.

Does this sound like a good way to go?  Once this project is finished we are
moving a lot of clients over to it from another solution, so I really want
to get this right the first time.

Chris

----- Original Message ----- 
From: "Chris Ochs" <ch...@paymentonline.net>
To: "Perrin Harkins" <pe...@elem.com>
Cc: <mo...@perl.apache.org>
Sent: Sunday, March 21, 2004 5:51 PM
Subject: Re: tied hashes frustration


> Ah yes pnotes.  You know actually I think you mentioned this once before
in
> a similar thread I brought up, not sure why I didn't remember it.
>
> > > 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.
> >
> It's not an option simply because I don't want to make people pass extra
> stuff that shouldnt' be needed (variables that the application server
> already has access to), not because of a design limitation.
>
> Chris
>
>
>
>
>
> -- 
> 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
>
>


-- 
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

Re: tied hashes frustration

[Chris Ochs <ch...@paymentonline.net>]

Ah yes pnotes.  You know actually I think you mentioned this once before in
a similar thread I brought up, not sure why I didn't remember it.

> > 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.
>
It's not an option simply because I don't want to make people pass extra
stuff that shouldnt' be needed (variables that the application server
already has access to), not because of a design limitation.

Chris





-- 
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

Re: tied hashes frustration

[Perrin Harkins <pe...@elem.com>]

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

Re: catching server errors

[Perrin Harkins <pe...@elem.com>]

On Sat, 2004-03-20 at 22:30, Chris Ochs wrote:
> Problem is if there is a compilation or runtime error, I cant' figure out
> how to catch it so I can log it or print the error to the screen.  I can't
> wrap it in an eval because for some reasons I don't completely understand it
> masks the opcodes that safe is trying to restrict access to.

Hmm, this doesn't sound like it has anything to do with mod_perl.  Maybe
you should ask about Safe on a general Perl list, or on usenet.

- 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

catching server errors

[Chris Ochs <ch...@paymentonline.net>]

I have an application that lets users load their own modules into it.
Following is the code I use to run it under Safe.pm:

$result = $safe->reval(require "$file.pm", $obj = $mod->new,
$obj->$command);

Problem is if there is a compilation or runtime error, I cant' figure out
how to catch it so I can log it or print the error to the screen.  I can't
wrap it in an eval because for some reasons I don't completely understand it
masks the opcodes that safe is trying to restrict access to.

Chris


-- 
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