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+Locking+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:47:11 EDT