Robert wrote:
>
> 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 ...
Indeed, that's exactly what Apache::Session::Store::Postgres does... so,
Gerald, there's no need for Semaphore after all, is it?
However, Angus complaints 11/5/01 that under Embperl, DESTROY is never
called and so no session is ever commited, but this is separate problem.
- Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
