perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From RobertCZ <rob...@robert.cz>
Subject Re: mdat/postgres - major perfomance problem?
Date Sat, 24 Jul 2004 08:19:12 GMT
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

Mime
View raw message