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:01:44 EDT