Mailing-List: contact embperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <03e901c46912$3473d230$fa0c0b0a@wingr2>
From: "Gerald Richter" <richter@ecos.de>
To: "RobertCZ" <robert@robert.cz>, <embperl@perl.apache.org>
References: <40F2517E.60403@pcv.cz> <013e01c468b9$49580440$fa0c0b0a@wingr2>
 <40F3B9D2.3010802@robert.cz>
Subject: Re: mdat/postgres - major perfomance problem?
Date: Tue, 13 Jul 2004 21:47:18 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8bit

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

You can pass parameters via

Embperl_Session_Args

see Config.pod


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

That will be the problem....

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

As far as I see not much people using %mdat. It seem like we need a
different locking strategie...

>> 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 recently discovered Cache::FastMMap, this might be an alterntive, also it
lacks synchronisation, which might be a problem for some applications.


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

see above

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

Yes, you are right. I can't say what wrong here at the moment

Gerald


>> - Robert
>>
>>
>>
>>
>
>
>
>
>
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
>> For additional commands, e-mail: embperl-help@perl.apache.org

---------------------------------------------------------------------------
Gerald Richter            ecos electronic communication services gmbh
IT-Securitylösungen * Webapplikationen mit Apache/Perl/mod_perl/Embperl

Post:       Tulpenstrasse 5          D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de          Voice:   +49 6133 939-122
WWW:        http://www.ecos.de/      Fax:     +49 6133 939-333
---------------------------------------------------------------------------
ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
---------------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org