view release on metacpan or  search on metacpan

lib/CGI/Session/Driver/flexmysql.pm  view on Meta::CPAN

is doing. In general, session data is not important and we can assume
all other applications should have priority with regard to everything.
Also, even though CGI::Session::MySQL obtains the locks, it would still
overwrite the data as soon as the "other thread" releases its lock,
which means that if two clients are using the same session id, the
locking gives absolutely no protection. MySQL already guranatees that
data is not corrupted when we update the same row from different
places at nearly the same time because it uses a queue for the requests.
It would be different if, once it detected that there is a lock, it
read the data again and SYNCHRONIZED it before updating. Then locking
would be helpful because no other client could synchronize at the same
time. But CGI::Session::MySQL doesn't actually do anything that requires
locking. 

A real use for locking would be to actually lock the session data while
the it's being used.  GET_LOCK and RELEASE_LOCK are usually not the
appropriate way to do this, especially for non-cgi applications where
the session may be in use for a considerable amount of time. I propose
that this locking be done using an extra field. GET_LOCK and RELEASE_LOCK
would be appropriate for locking the row while this extra locking field
is being checked and updated, and then this extra locking field would