Gerald Richter wrote:
>
> > >
> > > When using %mdat you should not use NullLocker, because you need
> locking,
> > > otherwise you may get corrupted data, because multiple request can
> happen at
> > > the same time to the same page.
> >
> > I apparently don't get it - I thought Postgres didn't need application
> > locking because it takes care of the translations itself so NullLocker
> > is appropriate. How wrong am I?
> >
>
> I know to less about Progres to say anything how Postgres handles this, but
> for %mdat you get the problem that one request retrieves the data, modifies
> it and before it can write it back, another process requests the data and
> modifies it. The second request sees the unmodified data, but should wait
> until the first process has written back the data. This is why for %mdat
> locking is important. For %udat this isn't such an issue because normaly you
> only have one request from one user at a time.
>
> Maybe Postgress or the Apache::Session Postgres drivers does some smart
> things about this. I don't know. Any Postgres expert who can shed some light
> into this ?
This is what Postgres' BEGIN/SELECT FOR UPDATE/UPDATE/COMMIT idiom is
for, I believe, but it can be done manually using the LOCK command too.
Now, if Apache::Session uses this, there's definitely no need for
external locking. Anybody knows how does Apache::Session over Postgres
do it? Any comments, Angus?
I'm going to look at it later today if nobody knows the answer, I'd
really like to use Postgres as my backend for Embpewrl sessions.
- Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
