I believe he is talking about the SET clause, not WHERE clause, of an
UPDATE statement (we've veered off optimistic locking).
Cayenne does indeed do comparisons to determine what to include in the
SET clause. It's been a few months since I looked at it, but I think it
brute-force compares every single attribute, so it is possible some kind
of mask to exclude things that never had set* called on them could be
useful. Of course, in a web application where you might have your
object bound to fields in the GUI, set* would be called all the time,
even if nothing changed.
I think this is worth discussing, but it might end up being a wash for
most things. For most objects, doing the comparisons isn't terribly
time consuming. Of course, for a large DataContext, this could slow
things down, too.
/dev/mrg
-----Original Message-----
From: Mike Kienenberger [mailto:mkienen..mail.com]
Sent: Thursday, September 01, 2005 11:34 AM
To: cayenne-use..bjectstyle.org
Subject: Re: Yet another optimistic locking question
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+Lockin
g+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:42:44 EDT