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/
This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:22:58 EDT