Re: [cgiapp] CAP::DBH and CAP::Session

["Curtis Hawthorne" <suppressed>]

Cees,
 
Nevermind, it was entirely my fault.  I still had a teardown sub left
over from before I was using CAP::DBH that would explicitly disconnect
the database.  Of course, with CAP::Session expecting all that to be
done automatically by DESTROYs, that didn't work so well.
 
Not feeling too smart right now...
 
Thanks for your help!
 
Curtis H.

>>> "Curtis Hawthorne" <suppressed> 6/22/2005
10:43:49 AM >>>

Cees,

I suspected mod_perl might be the problem too, but I have disabled it
for testing and am running as just a plain CGI script.  I went ahead
and
added a warn $@ statement to the PostgreSQL driver for CGI::Session
after the first eval in the store method when it tries to retrieve the
session information.  After doing this, I got an "execute on
disconnected handle" error in my Apache log, so it looks like the
handle
is being destroyed or disconnected for some reason.

Curtis H.

>>> Cees Hek <suppressed> 6/22/2005 9:15:09 AM >>>

On 6/22/05, Curtis Hawthorne <suppressed> wrote:
> So, I'm guessing what's happening is that the database handle inside
of
> CAP::DBH is getting DESTROYed before the session object.  Is there
any
> good way to get around this?

That should only happen if you explicitly close the database handle. 
CAP::Session will keep a reference to the database handle, so the
database handle will not be destroyed until after CAP::Session is
finished with it.

Another possibility is that your session never goes out of scope,
hence it is never automatically flushed.  This can happen under
mod_perl if you keep the session in a global variable, or trap it in a
closure.

Cheers,

Cees