PROTECTED]
Sent: Friday, January 18, 2002 1:53 AM
Subject: Re: Apache::Session getting DESTROYed in wrong order
On Friday, January 18, 2002, at 12:44 AM, Perrin Harkins wrote:
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines
I register a clean up handler to explicitly untie the session variable.
I have found that it's safer to put things in pnotes than to use globals and
cleanup handlers. We used a lot of cleanup handlers at eToys to clear
globals holding various request-specific things, and we started getting
On Friday, January 4, 2002, at 02:22 AM, Ken Williams wrote:
For the sake of thread completion, here's a script which demonstrates
the bug. It turns out to be a Perl bug (5.6.1, at least), not an
Apache::Session bug. I'll post to p5p after I post here.
I was surprised to find the it's
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines, they're just for
pedagogy):
%init
# 'local' so it's available to lower-level components
local *session;
my $dbh = ::get_dbh;
my $session_id =
On Friday, January 18, 2002, at 12:44 AM, Perrin Harkins wrote:
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines, they're just for
pedagogy):
%init
# 'local' so it's available to lower-level components
local
Hey,
For the sake of thread completion, here's a script which demonstrates
the bug. It turns out to be a Perl bug (5.6.1, at least), not an
Apache::Session bug. I'll post to p5p after I post here.
Note that $foo and %bar are cleaned up by refcount, but %foo isn't
cleaned up until global
# Won't get cleaned up properly
local %foo;
tie %foo, 'Dummy', name = '%foo';
local only make a copy of the original value and restores it at the end of
the scope, so %foo will not destroyed, but restored at the end of the scope.
I guess this is the reason my it still stays tied.
In
On Friday, January 4, 2002, at 02:48 AM, Gerald Richter wrote:
# Won't get cleaned up properly
local %foo;
tie %foo, 'Dummy', name = '%foo';
local only make a copy of the original value and restores it at the end
of
the scope, so %foo will not destroyed, but restored at the end
Hi Aaron,
I don't have a test case involving Apache::Session yet (I've been out of
town for a couple days), but here's a simple one in Perl that
demonstrates the DESTROY order problem:
--
#!/usr/bin/perl
{
package Outer;
sub
On Thursday, January 3, 2002, at 11:57 AM, Perrin Harkins wrote:
I don't have a test case involving Apache::Session yet (I've been out
of
town for a couple days), but here's a simple one in Perl that
demonstrates the DESTROY order problem:
That's sort of a weird example, since it has a
The circular reference was the only way I could think of to force an
object to be destroyed during global destruction.
What happens if you use a global?
Hmm, that may be - Mason does create more closures now than it used to.
It seems like only 'named' closures would create this problem,
On Mon, 31 Dec 2001, Ken Williams wrote:
Hey,
I'm having problems with Apache::Session, the symptom is that none of my
data is getting written to the database. It's not the nested-data
problem, since I'm not using any nested data structures.
After some investigation, I've discovered
On Thursday, January 3, 2002, at 02:02 PM, Jeffrey W. Baker wrote:
This seems like a really weird problem. The Store module is destroyed
while another module still has a reference to it. Unfortunately for you
and I, the only conclusion I have been able to draw is that Perl's
DESTROY
Hi Ken,
refcount destruction. I've declared %session as a locally-scoped
variable, so it should evaporate before global destruction, unless it's
got circular data structures or something. Anyone know what might be
going on?
Do you have a simple case we can test yet?
Aaron
Hey,
I'm having problems with Apache::Session, the symptom is that none of my
data is getting written to the database. It's not the nested-data
problem, since I'm not using any nested data structures.
After some investigation, I've discovered that the
Apache::Session::Store::MySQL::DESTROY
15 matches
Mail list logo
