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 Tue, 13 Jul 2004 10:30:42 GMT
Gerald Richter wrote:

>>(Docs still claim otherwise in places...)
>>    
>>
>
>this should be fixed...
>  
>

most confusing is 
http://perl.apache.org/embperl/pod/doc/Embperl.-page-6-.htm, it looks 
like it's master doc...

>>  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.
>  
>

Sorry for binary attachement - screenshot shows postgres indeed does 
wait for first select for update to finnish - however only if it's in 
explicit transaction so one has to call BEGIN before and be in the 
AutoCommit => 0 mode

The docs  for Apache::Session::Postgres say you have to manually specify 
Commit => X argument to the tie %hash, 'Apache::Session::Postgres', $id, 
... call to make clear what the commit policy is, but right now I can't 
figure out how Embperl 2 does it

If called with Commit => 1 (which means AutoCommit => 1 I hope), 
postgres DOES NOT wait for first SELECT FOR UPDATE but then I don't see 
how consistency is to be maintened

I'd love to use %mdat for all kind of neat trick namely for inter-user 
sql query caching, inter-user application locking (so 2 users don't edit 
the same record on the same web form etc), maybe track currectly 
connected users etcetcetc but this locking thing has to be fixed

Or maybe some other backend is better? I can't believe file or dbm will 
be any better and mysql is probably the same thing

I guess only real way to fix this problem is patch Apache::Session and 
Embperl to support read-only sessions, but that would be quit a lot of 
patching. Or maybe just passing from Embperl page Commit => X to 
Apache::Session would do the trick, I'm not sure - but that should be 
much easier to do, maybe just adding one method to the $req object?

>>PS. When I try to empty %mdat, maybe in base.html like
>>[-
>>    delete $mdat{$_} foreach keys %mdat;
>>    %mdat = ();
>>-]
>>it dumps empty session as expected. Now I comment out those delete
>>lines and reload and %mdat has the same content as before delete.
>>What's wrong?
>>    
>>
>
>Looks like Apache::Session (or the PG store) does not implement the CLEAR
>method
>  
>

I don't understand... Apache::Session::Store::DBI has only $self->update 
which does the obvious SQL UPDATE, Apache::Session::Store::Postgres 
inherits it without change (it modifies only connect and materialize 
methods), so they both use plain Apache::Session method clear which is 
in turn one line $self->{data} = {};

My guess %mdat = () should just work...

- Robert




Mime
View raw message