Deadlocking Apache::Session::MySQL

I'm working on a combined 5.6->5.8 and MP1->MP2 migration.

I've come across a scenario where unchanged code works on 5.6/MP1 such
that through various routes we twice tie a session object within a
request's life. Under the hood it seems to invoke get_lock(id) in the DB
on when doing the tie. I'm not exeactly sure where but I assume the second
invocation used to force, or follow, a release_lock(str) (Also invoked
in Apache::Session's destructor).

Within the 5.8/MP2 implementation this second invocation appears to
dead-lock on the second tie. One can see the get_lock waiting in the
database and I can only image that release_lock hasn't been called for
some reason.

Am on Apache::Session::MySQL (1.01), with differing (old and new)
Apache::Session versions.

I am curious whether anyone has memories of seeing this before or other
thoughts?

Thanks in advance,

Raf

Re: Deadlocking Apache::Session::MySQL

Hi,

> I've come across a scenario where unchanged code works on 5.6/MP1 such th=
at
> through various routes we twice tie a session object within a request's
> life. =A0Under the hood it seems to invoke get_lock(id) in the DB on when
> doing the tie. I'm not exeactly sure where but I assume the second
> invocation used to force, or follow, =A0a release_lock(str) (Also invoked=
in
> Apache::Session's destructor).

I suspect what happened is that you were using the same connection, so
when you asked for a lock you already had, it was given to you. Maybe
you're now using two separate connections.

> Am on Apache::Session::MySQL (1.01), with differing (old and new)
> Apache::Session versions.

Chances are you can get your code working just by making sure the same
connection is used in both cases, but my suggestions for the future
would be to either:

1) Use an up-to-date version of Apache::Session, and don't use the
canned MySQL one. Instead, use Flex so you can use
Apache::Session::Store::DBI, with transactions, on InnoDB tables.
Then you can also set the lock module to Null.

or

2) Use CGI::Session, which may not be perfect but is actively
maintained and generally easier to use.

- Perrin