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 20:25:29 GMT


Patrick Linskey commented on OPENJPA-359:

> If the version is handed off from the db server, then I agree with 
> you that is is a trivial problem. However in our implementation 
> the version is handed off from an instance of the persistence 
> provider of app server (in a cluster). E.g.
> NumberVersionStrategy.nextVersion() {
>     ...
>     return Numbers.valueOf(((Number) version).intValue() + 1);
> } 

Yes, but then, the previous number is used in an UPDATE or DELETE statement. If the row being
updated / deleted has been changed by a different VM, then the database will have a different
version value at that time, and the update / delete statement will fail (modified row count
of 0). So, while we don't fetch the number from the database, the database always contains
the most-recent clean version number, and updates only get into the database when the reader
had read that value.

Timestamps are more complicated, as has been discussed on this thread.

> Sleeping in a thread to avoid duplicate time stamp only solve its own problem.
> What about if there are 2 threads coming in at the same time (within the 15ms 
> time window) and asking for a new version. Without the synchronized block to 
> hand out the next value, the time stamp version created in both threads will be 
> same if sleep is used, which does not solve the initial problem. Even with the 
> current suggested solution, it does not guarantee to solve the cluster scenario.

I agree -- this entire domain is rife with problems when transactions are shorter than the
resolution available. I just do not think that adding synchronization to attempt to partially
fix the situation is really worth the cost in all the use cases where transactions are known
to be longer than the resolution.

In any event, I understand that there is some value to what you're proposing; I just don't
think that we should change our current behavior, because it's good enough for many users,
and has characteristics (lack of synchronization) that is advantageous over the incremental
improvement that you're suggesting. So, I could see room for a new versioning strategy or
some sort of option to configure how the timestamp behavior works.

> 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