Ok. I see.
Wouldn't you still want to also do the compare after the mask filtered
out things since it may be a case of multiple updates that leave the
data matching the original state?
On 9/1/05, Gentry, Michael (Contractor) <michael_gentr..anniemae.com> wrote:
> 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:49:00 EDT