Right, I just discussed this with Mike in IRC and I get it now. That's
really too bad :( Still, I think there is value to adding the BitSet I
mentioned. We'll have to try it out to see the performance impact.
Gili
Gentry, Michael (Contractor) wrote:
> 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 - 14:25:42 EDT