[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
AW: [eclipselink-dev] Test EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with JTA/non-JTA data sources
|
Hi Tom,
I just reran the test. This is the current stack trace:
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:990)
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)
at sun.reflect.GeneratedMethodAccessor267.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
>> 1. update some test data and flush the changes to the database
977-980:
Employee emp2 = (Employee)result.get(1);
String newName = ""+System.currentTimeMillis();
emp2.setFirstName(newName);
em.flush();
>> 2. provoke an OptimisticLockException so that the current transaction is marked for rollback
981-984:
emp2.setLastName("Whatever");
emp2.setVersion(0);
try{
em.flush();
>> 3. read the test data updated in step 1) and assert that the changes are there
985-990:
}catch (Exception ex){
em.clear(); //prevent the flush again
// Query may fail in server as connection marked for rollback.
try {
String eName = (String)em.createQuery("SELECT e.firstName FROM Employee e where e.id = " + emp2.getId()).getSingleResult();
assertTrue("Failed to keep txn open for set RollbackOnly", eName.equals(newName));
We think that for the flush on 980, a connection from the JTA data source is being used and for the query on line 989 a connection from the non-JTA data source.
Hence the result of the flush on 980 is not visible to the query on 989.
-Adrian
====
Adrian Görler
SAP AG
Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
-----Ursprüngliche Nachricht-----
Von: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx] Im Auftrag von Tom Ware
Gesendet: Dienstag, 8. Dezember 2009 16:09
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re: [eclipselink-dev] Test EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with JTA/non-JTA data sources
Hi Sabine,
The line numbers in my test do not correspond with the ones in your exception
trace and I cannot tell from the error message which assertion is failing for
you. What is on the line that causes the exception for you?
(EntityManagerJUnitTestSuite.java:994)
-Tom
Kevin Yuan wrote:
> Hi Sabine,
> This test passed on both JTA and non-JTA datasource on both WebLogic and
> WebSphere, I don't think that's EclipseLink behaves incorrect in this
> situation, but I am not familiar with NetWeaver server. Probably you
> have to follow on the setting with the server. I will let you know if I
> find more info.
>
> Regards,
> Kevin
>
> Heider, Sabine wrote:
>>
>> 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
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev