RE: Yet another optimistic locking question

From: Gentry, Michael \(Contractor\) ("Gentry,)
Date: Thu Sep 01 2005 - 12:08:50 EDT

  • Next message: Gentry, Michael \(Contractor\): "RE: Yet another optimistic locking question"

    BLOB optimistic locking will always be slow. The optimization you are
    referring to wouldn't help with the WHERE clause generation, it could
    only help in the SET clause, which means if you lock on a BLOB, you have
    to send it over to the DB regardless of if it has changed or not.

    /dev/mrg

    -----Original Message-----
    From: Gili [mailto:cowwo..bs.darktech.org]
    Sent: Thursday, September 01, 2005 11:47 AM
    To: cayenne-use..bjectstyle.org
    Subject: Re: Yet another optimistic locking question

            I think you misunderstand me.

            I'm saying that in part 3 Cayenne compares its internal
    representation
    of 1 and 2 and it gathers up all fields that the user has changed during

    the transaction. Then it generates a "UPDATE SET" statement only
    consisting of fields the user has changed. Correct?

            All I am saying is that we can optimize comparison on Cayenne's
    part
    (when comparing part 1 and 2) because you could use a BitSet to know
    whether a field has been touched or not without having to compare the
    entire field value.

            This even makes BLOB optimistic locking much cheaper because the
    only
    time this becomes expensive. If we can wrap the BLOB data in some
    read-only structure so the getter() returns an unmodifiable array, then
    we can quite easily detect whether a blob has been changed or not
    without comparing its entire value.

            We still have send the changed data to the DB and granted this
    is slow,
    but I'm saying we can optimize the comparison that occurs before that.
    Did I miss something? :)

    Gili

    Mike Kienenberger wrote:
    > 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+Lock
    ing+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/
    >>
    >
    >

    -- 
    http://www.desktopbeautifier.com/
    



    This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 12:08:54 EDT