Re: Yet another optimistic locking question

From: Mike Kienenberger (mkienen..mail.com)
Date: Thu Sep 01 2005 - 11:48:56 EDT

  • Next message: Gili: "Re: Yet another optimistic locking question"

    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