No, that doesn't work. The "checking" part is executed as part of the
database operation.
The database "checks" if the value has changed as part of the update
statement, not the java code. We supply the original values as part
of the query, and the database does the comparison. Optimistic
locking in general isn't specific to cayenne so the process is well
understood and probably as optimized as it can be. Optimizations to
the concept are the timestamp and versioning alternatives of
optimistic locking where you only lock on a timestamp (assumes that
any database operation must occur at different timestamps) or versions
(which forces the caller to maintain versioning). The downsides of
these optimizations are that they take up extra database space (on
field per table) and that they consider "differences that make no
difference" as a difference.
Ie, attribute locking works even if, in the mean time, someone changed
a field value then changed it back. But versioning/timestamping will
fail even if the current state is the same as the original perceived
state.
The downsides of attribute locking is that it requires more bandwidth
(multiple where clauses transmitted) and processing on the database
(multiple where clauses computed)
On 9/1/05, Gili <cowwo..bs.darktech.org> wrote:
>
> Here is an idea for us to further optimize the process. Can we perhaps
> detect whether the user ever modified a field without comparing the two
> states? For example, if one of my fields is a large BLOB (byte[]) then
> when I get() that array I could concievable modify it. So then what I'm
> thinking is if the user ever invoked get() or set() on that field, we
> toggle the appropriate value in a BitSet to indicate we should look at
> it in step 3. If the user never touched a field, we can very quickly
> (regardless of its size) know that it has not been modified without
> comparing the actual contents.
>
> Using a BitSet this would be very cheap to do as well. What do you think?
>
> Gili
>
> Mike Kienenberger wrote:
> > 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/
> >>
> >
> >
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:33:51 EDT