Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipselink-dev] Test EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with JTA/non-JTA data sources

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

 

Hi all,

 

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:

  1. update some test data and flush the changes to the database
  2. provoke an OptimisticLockException so that the current transaction is marked for rollback
  3. 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?

 

Best regards,

Sabine

 

Sabine Heider
SAP AG

Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx

 

 


Back to the top