On Wed, Mar 19, 2008 at 6:53 PM, Robert Landrum <[EMAIL PROTECTED]>
wrote:
> Well... it's been about 15 minutes since we've seen the session
> problem...
>
> tied(%HTML::Mason::Commands::session)->save;
> untie %HTML::Mason::Commands::session;
>
> That seemed to do the trick. I'm keeping my fingers crossed though.
>
> Thanks for the suggestion. For whatever reason, I just figured it wasn't
> worth trying, so I never bothered. The real question is, why isn't the
> untie triggering the underlying tied object to be destroyed?
My experience with tie-fu is limited, but this from perldoc perltie led me
to believe that the problem might be that DESTROY is not called by untie(),
but when the object is garbage collected:
UNTIE is called when "untie" happens, and
DESTROY is called when the tied variable is garbage collected.
Perhaps what you want to do is have that ->save() method called in UNTIE?
mike
> And why does the apache process continue to serve requests without
> cleaning up the object? Maybe I was given bad versioning information from
> our SA, and we have different mod_perl versions... versions that perhaps do
> garbage cleanup differently. Or maybe it's perl that's doing the garbage
> cleanup different.
>
> Either way, I appreciate the help.
>
> Rob
>
>
> On Wed, Mar 19, 2008 at 6:20 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Mar 19, 2008 at 6:04 PM, Robert Landrum <[EMAIL PROTECTED]>
> > wrote:
> > > Nope... no front end proxy.
> >
> > That does make your mod_perl processes sit around for a second or two
> > after the request is done. I don't know why you would see the effect
> > on one request and not another though.
> >
> > > We just call untie %session; to commit it.
> >
> > Yeah, that should do it. Since you're already in voodoo territory
> > though, you might as well try an explicit write to see if it makes a
> > difference.
> >
> > - Perrin
> >
>
>
