Forgot to mention, for primitive types (like int, float, etc) the
getter wouldn't flag the field as 'touched' because they're returned by
value. So for the majority of cases (i.e. Strings) we'd have a *very*
fast comparison.
Gili
Gili 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/
This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:33:33 EDT