[jira] Updated: (OPENJPA-359) OptimisticLockException NOT thrown for entity using Timestamp Version when update from concurrent persistence contexts

["Albert Lee (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENJPA-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Albert Lee updated OPENJPA-359:
-------------------------------

    Attachment: OPENJPA-359.1.patch

Attached is an alternative implementation of the nano precision timestamp versioning. This is based on the JRE 1.5 System.nanoTime() support. It does not use synchronization block and should be thread-safe.

A new NanoPrecisionTimestampVersionStrategy is created using alias "nano-timestamp". This is the default date/timestamp version strategy if Java version >= 5.

Due to the JRE 1.4 compilation requirement in the maven build process, the new TimestampHelper class in the openjpa-persistence module uses Reflection to invoke System.nanoTime() and TimeStamp.setNanos() methods.  If there is other alternative to get around the 1.4 maven compilation problem, I would prefer to call these methods directly but I don't have a good solution other than using Reflection. Suggestion is welcome.

I'll wait until EOD Monday to commit this change.

Thanks,
Albert Lee.

> OptimisticLockException NOT thrown for entity using Timestamp Version when update from concurrent persistence contexts
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-359
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-359
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.0.0
>         Environment: WIntel 32 
>            Reporter: Albert Lee
>            Assignee: Albert Lee
>            Priority: Minor
>         Attachments: OPENJPA-359.1.patch, 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.