RobertCZ wrote:
Angus Lees wrote:
At Tue, 13 Jul 2004 12:30:42 +0200, RobertCZ wrote:
Gerald Richter wrote:
I tried to play with it and it seems that Postgres as a store does
SELECT ... FOR UPDATE,
To me it looks like only one Apache child is working and other are
just waiting for session commit.
Mmmh, yes this seems to be the case.
I am not sure how select for update works, for the other storages the
locking works the way, that multiple pages can read at the same time, only
if one page writes it tries to get an exclusive lock. So just do write only
at the end of the page, normaly solves this locking problem.
If thats what every other storage does, then every other storage has a
pretty severe race condition. This is fine if the data you are
storing in %mdat (or %udat) isn't dependent on what the previous %mdat
data was (eg: storing "the last visitor" is ok, a page counter is not ok).
The problem is that perl cannot know when fetching the session data,
whether you are intending to modify it or not. It seems the Postgres
backend is taking the conservative approach, unlike every other
Apache::Session store (and against the behaviour described in the
Apache::Session docs).
BTW, here's interesting comment from Phalanx project
http://cpanratings.perl.org/d/Apache-Session
- Robert
|
