Yep!
On 9/1/05, Gili <cowwo..bs.darktech.org> wrote:
>
> And I forgot to mention, in step 3 I assume we look at the return value
> from the DB and if we expected 1 change and got 0 this means we detect
> that our DB representation was out of date and we throw an exception,
> correct?
>
> Gili
>
> Mike Kienenberger wrote:
> > 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/
> >>
> >
> >
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:17:38 EDT