in reply to Re^6: Apache::Session problems under high load
in thread Apache::Session problems under high load

It does, It get the sessionlock direct inside new and not at the writeback stage. That may resolve the issue that the anonmonk has, since there is no race between the concurent requests.
Boris
  • Comment on Re^7: Apache::Session problems under high load

Replies are listed 'Best First'.
Re^8: Apache::Session problems under high load
by perrin (Chancellor) on Oct 27, 2004 at 17:45 UTC
    It does what you say, but not for MySQL. From the docs:
    Note that the Transaction argument has no practical effect on the MySQL and Postgres implementations. The MySQL implementation only supports exclusive locking, and the Postgres implementation uses the transaction features of that database.
      But the 'exclusive locking' is what the monk want. IMHO. And Apache::Session does that if 'Transaction => 1' even when this is no real transaction, it prevents others to write to that session until the session is untied. Whereas without 'Transaction => 1' another request can overwrite the sessiondata with older data.
      Boris
        You're missing the point. If he is using Apache::Session::MySQL he already hasexclusive locking. It has no other mode and is totally unaffected by the Transaction option. The same goes for Postgres and Oracle. So, it's best to find out which one he's using before offering this advice, because it may not do anything at all.