Yeah, it's basically an atomic db operation that says UPDATE set
values WHERE all fields marked for optimistic locking haven't changed
values from the last time we read them.
On 9/1/05, Gili <cowwo..bs.darktech.org> wrote:
>
> Oh my. It all makes so much more sense now... So if I understand it
> correctly,
>
> 1) We store the perceived DB value somewhere
> 2) We store the cached (maybe modified) value elsewhere
> 3) When a commit occurs, we compare the objects in 1 and 2, then issue a
> UPDATE only for fields which have changed.
>
> Cool :) This also sounds quite efficient to me.
>
> Thank you,
> Gili
>
> Gentry, Michael (Contractor) wrote:
> > Optimistic locking never locks the row in the database (it is
> > optimistic). Read:
> >
> > http://www.objectstyle.org/confluence/display/CAY/Optimistic+Locking+Exp
> > lained
> >
> > It explains how Cayenne can ensure that no changes occurred between the
> > SELECT and UPDATE phase. If you still have questions I'll try to answer
> > them.
> >
> > Thanks,
> >
> > /dev/mrg
> >
> >
> > -----Original Message-----
> > From: Gili [mailto:cowwo..bs.darktech.org]
> > Sent: Thursday, September 01, 2005 12:06 AM
> > To: cayenne-use..bjectstyle.org
> > Subject: Yet another optimistic locking question
> >
> >
> >
> > A question about how optimistic locking is currently
> > implemented. Do we
> > implement it like this?
> >
> > 1) Lock row
> > 2) Read row
> > 3) Compare read row to DataObject version of row
> > 4) If values mismatch, unlock the row and throw an exception
> > 5) If values match, continue with update and unlock row
> >
> > or do we not lock the database at all? If we don't lock it at
> > all, how
> > can we ensure that no changes occur after step 3 but before step 5?
> >
> > Thank you,
> > Gili
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:07:59 EDT