On Jan 4, 2007, at 1:12 PM, Michael Dick wrote:
By default OpenJPA uses optimistic transactions (ie the transaction
does not
lock database records). Since the database records aren't locked
there is a
chance that a second transaction can modify the record before the
first one
completes. There's a better explanation in the OpenJPA manual here :
http://incubator.apache.org/openjpa/docs/openjpa-0.9.6-incubating/
manual/manual.html#jpa_overview_trans_types.
The OptimisticException you're seeing in the log is thrown when
OpenJPA
detects that a record has been changed by another thread. The
exception
should be thrown back to the transaction manager though so there
might be a
bug there, or something is intercepting it.
Does the problem occur when you run one test at a time, or does it
only
occur if you run several of them at once? If you're running more
than one
test and they touch the same rows of the database, that might
explain why
you're getting the exception (but not why it isn't making it back
to the
app).
This is a single threaded test.
That's my first guess. If you can easily reproduce the problem it
might help
to turn on OpenJPA tracing and see if that shows two transactions
using the
same entity.
I'll take a look.
-dain
