openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <>
Subject [jira] Commented: (OPENJPA-359) OptimisticLockException NOT thrown for entity using Timestamp Version when update from concurrent persistence contexts
Date Mon, 10 Sep 2007 05:41:29 GMT


Patrick Linskey commented on OPENJPA-359:

> When you say clustered environment, do you mean multiple appl servers 
> (in a cluster) accessing the same db server? 


> I agree with you that Versioning support in cluster environment is a hard 
> problem and it is not only for Timestamp but any type. Until there is a central
> "server" that hands out unique version id, it will remain to be a insoluble problem.

I don't understand. IMO, versioning in a clustered environment is a trivial problem 
when using the monotonically-incrementing number approach. The only "problems"
arise when using timestamps, and arguably, these aren't problems, but rather just
limitations imposed by the timing needs of the application.

FTR, with a monotonically-incrementing version number, the database itself acts
as the central server.

> sleeping for 2ms per se is an artificial performance and concurrency inhibitors 
> which I don't recommend. 

By my definitions, sleeping for 2ms does incur a performance cost, but does not 
incur any concurrency problem at all. In fact, doing so avoids the concurrency 
problem introduced by the new synchronized block.

> OptimisticLockException NOT thrown for entity using Timestamp Version when update from
concurrent persistence contexts
> ----------------------------------------------------------------------------------------------------------------------
>                 Key: OPENJPA-359
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.0.0
>         Environment: WIntel 32 
>            Reporter: Albert Lee
>            Priority: Minor
>         Attachments: OPENJPA-359.patch
> We ran a test using Timestamp as the version field in an entity, the following (pseudo)
test failed when an OptimisticLockException is expected:
>     em1.persist( e0(pk1) );
>     e1 = em1.find(pk1);
>     e2 = em2.find(pk1);
>     e1.setAttr( "new1");
>     e2.setAttr( "new2");
>     em1.merge( e1 );
>     em2.merge( e2 );    <<<< Expect an OptimisticLockException
> The cause of this problem is because the TimestampVersionStrategy.nextVersion returns
a java.sql.Timestamp(System.currentTimeMillis()); In the Wintel environment, the currentTimeMillis()
only has approximately 15ms resolution. When 2 subsequent Timestamp version objects are requested
within this 15ms interval, both has the same version value. Therefore the em2.merge does not
detected the versions difference between o1 and o2, hence no exception is thrown.
> Due to this behavior, the same test case may failed intermittenly depends on the currentTimeMillis()
resolution and the time when a timestamp version is created.  From some preliminary tests,
the resolution for  wintel, linux and z/os are about 15ms, 2ms and 2ms respectively.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message