Hey.. Yes we're still talking about a multithreaded issue along the same
line..

The issue is that on both threads this occurs

1) does the pk Object exist?
2) if not create the pk Object
3) assign the pk Object to the object to persist
4) persist object

In both threads at step 1) it is determined that the same object (determined
by the business key) doesn't exist.
So both threads continue onto step 4) and attempt to persist the same object
in essence.

In my code path on each thread, steps 1-4 happen multiple times for
different objects and at the end of 1000 iterations a commit occurs.

So as described some objects are common to both threads and as such inserts
of these rows that violate the unique key index will result in an exception
causing all the other objects (which could have been persisted) to rollback.

So the idea is that if in fact the objects are the same then rather than
throwing an exception it should then query the object and use it in it's
stead (updating it if necessary as other fields on the object or the pk
object may have changed)

In my test case KeyClass is the pk object and MasterClass is the object
whose @Id column is the KeyClass object





--
View this message in context: http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581263.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.