db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Optimistic locking - not 100% reliable without triggers?
Date Tue, 14 Mar 2006 20:15:38 GMT
Hi Jörg,


On Mar 14, 2006, at 12:03 PM, Jörg von Frantzius wrote:

> Craig L Russell schrieb:
>> Hi Jörg,
>>
>> On Mar 14, 2006, at 11:34 AM, Jörg von Frantzius wrote:
>>
>>> Craig L Russell schrieb:
>>>> Hi Jörg,
>>>>
>>>> On Mar 14, 2006, at 10:42 AM, Jörg von Frantzius wrote:
>>>>
>>>>> Hello Craig,
>>>>>
>>>>> do you or does anybody else see a problem in deferring  
>>>>> verification and update of versions to the end of the transaction?
>>>>
>>>> In my experience, deferring verification and update of versions  
>>>> to the end of the transaction is best practice. Of course, if  
>>>> you use the flush method the implementation has no choice.
>>> Is flush() required to update version columns?
>>
>> I'm afraid this question is ambiguous. I'll answer both possible  
>> interpretations of the question.
>>
>> 1. Is the user required to call flush in order to update version  
>> columns? No. Commit will also update version columns.
>>
>> 2. If the user calls flush(), is the implementation required to  
>> update version columns? Yes. Flush forces changes to the  
>> datastore, and reports exceptions, including version mismatches.
> As version data is not directly accessible by any user queries,  
> would it have any consequences to exempt optimistic version  
> information from the requirement "forces changes to the datastore"?  
> Can you think of any use-case where application code (or external  
> systems) rely on version information being stored during flush()?
>
> For the verification itself I think it is not necessary to update  
> version information during flush().

The reason we added flush to JDO 2 was so an application could find  
out if a commit would encounter any issues, without actually  
committing the transaction. Especially in a web or application server  
environment, the application wants to know if the changes are good;  
but the application doesn't have the authority to commit the  
transaction.

The semantics of flush are that changes in the cache are now in the  
datastore. So a commit immediately following flush has no work to do.

Craig

>>
>> Craig
>>
>>>>
>>>> Craig
>>>>
>>>>> Compared to JPOX' current implementation, in my opinion this  
>>>>> would decrease database deadlock probability a lot. At the  
>>>>> moment, locking would be dispersed over time of the  
>>>>> transaction, as verification happens with every update request  
>>>>> issued. For implications on the number of statements, please  
>>>>> see the said JPOX issue <http://www.jpox.org/servlet/jira/ 
>>>>> browse/CORE-2743>.
>>>>>
>>>>> Regards,
>>>>> Jörg
>>>>>
>>>>> Craig L Russell schrieb:
>>>>>> Oops,
>>>>>>
>>>>>> On Mar 14, 2006, at 9:53 AM, Craig L Russell wrote:
>>>>>>
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> On Mar 14, 2006, at 4:01 AM, Eric Samson wrote:
>>>>>>>
>>>>>>>> Hello Jörg
>>>>>>>>
>>>>>>>>
>>>>>>>> One common portable solution to this is to acquire locks
 
>>>>>>>> during the conflict detection step (using SELECT for UPDATE
 
>>>>>>>> instead of simple SELECT).
>>>>>>>>
>>>>>>> This would typically involve a user configuration setting,  
>>>>>>> either globally or on a per-class basis. It's been  
>>>>>>> implemented in e.g. the SunOne application server CMP as  
>>>>>>> policy "lock-when-loaded" on a persistent class.
>>>>>>
>>>>>> This is noise. Doesn't apply to optimistic scenarios. Eric's  
>>>>>> comments are spot on.
>>>>>>
>>>>>> Craig
>>>>>>>>
>>>>>>>> Another approach could be to perform the conflict detection
 
>>>>>>>> and the update at the same time (statement like “UPDATE
 
>>>>>>>> WHERE pk=OID AND TS=ts”), but it raises some concerns for
 
>>>>>>>> the conflict resolution (most JDBC drivers are not able to
 
>>>>>>>> indicate which rows raised an exception).
>>>>>>>>
>>>>>>> I don't follow this. The UPDATE statement only updates one  
>>>>>>> row at a time so I don't know why this would be an issue.  
>>>>>>> This is the recommended solution from me.
>>>>>>>
>>>>>>> Craig
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>> **...****.:**** Eric Samson, Founder & CTO, x****calia******
>>>>>>>>
>>>>>>>> //Service your Data!//
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------

>>>>>>>> ---------
>>>>>>>>
>>>>>>>> *De :* Jörg von Frantzius  
>>>>>>>> [mailto:joerg.von.frantzius@artnology.com]
>>>>>>>> *Envoyé :* mardi 14 mars 2006 12:20
>>>>>>>> *À :* jdo-dev@db.apache.org <mailto:jdo-dev@db.apache.org>
>>>>>>>> *Cc :* JDO Expert Group
>>>>>>>> *Objet :* Optimistic locking - not 100% reliable without
 
>>>>>>>> triggers?
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> JPOX optimistic version verification entirely takes place
 
>>>>>>>> within the VM, by reading a version column and comparing
it  
>>>>>>>> with an expected value. When it verfies OK, JPOX proceeds
 
>>>>>>>> and updates the version column with a new value. That means
 
>>>>>>>> verification and update of version do not happen atomically,
 
>>>>>>>> at least not on the database level, unless at least  
>>>>>>>> REPEATABLE_READ is used.
>>>>>>>>
>>>>>>>> Now if two threads or processes want to update the same row,
 
>>>>>>>> and happen to verify the row's version at the same time,
it  
>>>>>>>> is theoretically possible that they both decide to update
 
>>>>>>>> it, i.e. none of them will receive a  
>>>>>>>> JDOOptimisticVerificationException. Using READ_UNCOMMITTED
 
>>>>>>>> instead of READ_COMMITTED for verifying the version column
 
>>>>>>>> will increase chances of detecting a conflict, but still
a  
>>>>>>>> conflict can remain undetected.
>>>>>>>>
>>>>>>>> In Oracle's suggestion for implementing optimistic locking,
 
>>>>>>>> the process will write the same optimistic version that it
 
>>>>>>>> had previously read, and a trigger on the database will do
 
>>>>>>>> the verification and increment the version if it had not
 
>>>>>>>> been so yet. I guess that the trigger executes atomically,
 
>>>>>>>> so conflicts will always be detected.
>>>>>>>>
>>>>>>>> Am I wrong here somewhere or do we really need triggers to
 
>>>>>>>> have 100% reliability of conflict detection?
>>>>>>>>
>>>>>>>> Thanks for any hints,
>>>>>>>> Jörg
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/ 
>>>>>>> products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/ 
>>>>>> products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>>
>>>> Architect, Sun Java Enterprise System http://java.sun.com/ 
>>>> products/jdo
>>>>
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message