Hi,
does
anyone have an opinion on the error described below?
I’m
under the impression that EclipseLink behaves incorrectly in this situation,
but it could also be that there is a problem with our application server that I
would have to follow on.
Thanks
and best regards,
Sabine
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx] On Behalf Of Heider, Sabine
Sent: Dienstag, 1. Dezember 2009 12:39
To: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Test
EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with
JTA/non-JTA data sources
when
running on the NetWeaver server, the test
EntityManagerJUnitTestSuite.testSetRollbackOnly fails with the following
assertion error:
junit.framework.AssertionFailedError:
eName was 'testRefreshRemoved' but expected '1259661366483'
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at
org.eclipse.persistence.testing.tests.jpa.advanced.EntityManagerJUnitTestSuite.testSetRollbackOnly(EntityManagerJUnitTestSuite.java:994)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBareServer(JUnitTestCase.java:463)
at
org.eclipse.persistence.testing.framework.server.TestRunnerBean.runTest(TestRunnerBean.java:87)
What
the test basically does is that it executes the following steps inside a single
JTA transaction:
- update
some test data and flush the changes to the database
- provoke
an OptimisticLockException so that the current transaction is marked for
rollback
- read
the test data updated in step 1) and assert that the changes are there
Step
3) fails on NetWeaver – the query can still be executed but it returns the
unmodified (i.e. committed) data.
I
did some debugging and found out that step 1) uses the data source from
PersistenceUnitInfo. getJtaDataSource(), while in step 3) the data source is
obtained from PersistenceUnitInfo. getNonJtaDataSource(). Thus we ended up with
two different connections, and as transaction isolation
TRANSACTION_READ_COMMITTED is used we don’t see the uncommitted changes from
the flush operation before.
It
seems wrong to me that EclipseLink uses the non-JTA data source in that
situation, but I’m unable to decide whether it is a general problem or rather
caused by some peculiarity of our server. What happens on different application
servers?