Not sure if this is related but do you use
MasonX::Request::WithApacheSession to do your sessions? I ran into
trouble accessing $m->session->{} parameters where the page would lock
up. It had something to do with the locking on the session table. I
remember now... It was when I was calling a component and using
$m->session->{} parameters like so:
<& 'comp.mas', %ARGS, param1 => $m->session->{param1} &>
On certain pages(not all IIRC) that had a component call like about
would cause MySQL to lock up. I believe that I just modified my scripts
and removed any $m->session variables out of component calls.
Justin
On Mon, 2006-02-27 at 15:20 -0500, Mike M. wrote:
> Hi,
>
> We're using apache 1.3.33, mod_perl 1.29, HTML::Mason 1.26 (we cannot
> upgrade because of a strange mason method bug with our app in all masons
> above 1.26), DBI 1.48, DBD::Oracle 1.16. We have mason caching turned
> on in production.
>
> We keep running into a weird problem. Every couple weeks or so, our app
> starts opening connections like mad to the oracle database and never
> seems to let them go. This ends up tanking our database and app.
>
> Today, we think we may have finally figured out what was happening after
> months of looking through our queries to see if there was some sort of
> performance problem. We noticed that even though our app had slowed
> down to a crawl and the database cpu was high, everything still worked
> except for two pages. Every time we hit one of those two pages, it'd
> just tank the database and hang. Even after restarting the database and
> web server they would still tank. So, we came up with the random
> thought, why not delete the cached version of these files and see what
> happens. Lo and behold, the problem went away! We're totally stumped.
> How could a cached version of a mason page cause our database to tank?
> I mean, we killed the apache processes that could've had them open and
> that didn't solve the problem. It was only when we actually removed the
> mason cache files that everything went back to normal; and, we didn't
> even restart the web server after removing these files.
>
> Any ideas?
>
> Thanks,
> -Mike M.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Mason-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mason-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
