Yes. You would. The mask is meant to act like a hash of sorts. It'll
tell you if something was not touched but just because something was
touched doesn't mean it was modified :)
Ok, I'm off for lunch. I'll rejoin this conversation when I get back :)
Gili
Mike Kienenberger wrote:
> 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/
>>>
>>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:57:29 EDT