Hi, > 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).
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
