Skip to main content

[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


Back to the top