Right, that's what I'm talking about.
I think that even in a GUI domain this will help. Users aren't going to
necessarily "touch" every single field. I think/hope that, like any
other form of caching, this mechanism's benefits will always be greater
than its overhead. It's a BitSet after all... Very fast, very light. :)
Gili
Gentry, Michael (Contractor) 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:55:58 EDT