in reply to Re: Re: Re: Apache Session problem after update
in thread Apache Session problem after update

The suggestion for debug running has lead me to some wierd results. It ran fine??? I have re-built perl and all modules. I have traced it done to one problem. I'm going to include the code. I'm sure that I'm really understanding the problem, but can tell you all the symptoms.

On the line:

$sth->bind_param(1,$session{snmember});

If I use a hard plug such as:

$sth->bind_param(1,"*");

Everything works fine. Otherwise I get no update to the session data and the error message of:

(in cleanup) Can't call method "prepare_cached" on unblessed reference at /usr/local/lib/perl5/site_perl/5.8.1/Apache/Session/Lock/MySQL.pm line 69 during global destruction.
(in cleanup) Can't call method "acquire_write_lock" on an undefined value at /usr/local/lib/perl5/site_perl/5.8.1/Apache/Session.pm line 569 during global destruction.

The query has even run succesfully for both the session handle and the bchoices handle ($dbs and $dbh). It will not update the session data during that crash though. I'm sure I'm missing something with my ugly code that you guys will spot right a way (and probably make me have to fix thousands of line of code I've messed up in the long run :-)

Thanks again for all the help, I have included the stripped down test code below:

Mark

P.S. To test I have been running it once with no params and then the second time cutting and pasting the session_id as provided by the Output into the session_id=. This code has worked with no problems on 5.6.1 for over a year!

#!/usr/bin/perl -w

use strict;
use warnings;
use CGI ':standard',':html3','-no_xhtml';
use DBI;
use Apache::Session::MySQL;

my ($database,$username,$password)=("dbi:mysql:bchoices:localhost","stdadmin","0i812");
my $dbh = DBI->connect($database,$username,$password);
my $dbs = DBI->connect("dbi:mysql:session:localhost",$username,$password);

my %session;
my $sess_id = param('session_id');

tie %session, "Apache::Session::MySQL", $sess_id,
{
Handle => $dbs,
LockHandle => $dbs
};


if (param('session_id'))
{
my $sth=$dbh->prepare("SELECT COUNT(?) as snemployer FROM member");
$sth->bind_param(1,$session{snmember});
$sth->execute();
my $member=$sth->fetchrow_hashref();
$sth->finish();
print "Session Print 2:".$session{snmember}."-".$session{_session_id}."-".$session{test}."-".$member->{snemployer}."\n";
$session{test}="HI There";
}
else
{
$session{snmember}="*";
$session{test}="HI";
print "Session_ID:".$session{_session_id}."\n";
}

print "Session Print 1:".$session{snmember}."\n";

untie (%session);
  • Comment on Re: Re: Re: Re: Apache Session problem after update

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Apache Session problem after update
by perrin (Chancellor) on Oct 06, 2003 at 13:29 UTC
    Try replacing your untie at the end with tied(%session)->save(). I think you might be having problems with the new randomization of the order of destruction in Perl 5.8.1.
      That got it working, same error but it does work now. I'm confused that I seem to be writing the most basic of code, and getting ghtese errors? I know it is not great code, ut is it that bad (you can say yes!!).

      Mark

      P.S. THANK_YOU THANK-YOU THANK-YOU!! I thank-you again for the time you have spent helping me!!
        I think the problem is not your code, but rather an interaction between Perl 5.8.1 and Apache::Session. When your CGI ends, Perl tries to destroy all the objects. Some of the Apache::Session objects have DESTROY methods that get triggered when this happens. In Perl 5.8.1, you can no longer count on the order in which these get called, and I think that somehow the object holding the database handle is getting destroyed before another object that wants to use it. One way to find out would be to go into the A::S source code and add warning messages to all the DESTROY methods so you can see what order they get called in.

        Unfortunately, the simplest fix for you would probably be to go back to 5.6.1. It has better performance anyway, so it might be a better choice. The only reasons to use 5.8.x are unicode and threads.

      Hi We are facing a similar problem in IIS, but using tied at the end fails the DB updates. COuld you please suggest on this.

        I don't know anything about IIS, but unless you tell us how things fail for you, we (as a collective) can't help you much.