Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: AW: [eclipselink-dev] Test EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with JTA/non-JTA data sources 
Hi Sabine and Adrian,

  I'll try to cover both of your questions here.
First of all, for Adrian's question regarding non-transactional reads. We have decided that for most users, prior to any changes occurring via EclipseLink, it is preferable to use the optimization that reads through the non-transactional connection. We provide a persistence unit property that allows a user to override this default behavior. See "eclipselink.jdbc.exclusive-connection.mode" under the following link: 

http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#Using_EclipseLink_JPA_Extensions_for_JDBC
Next, the issue with the setRollbackOnly test: I had a discussion with some of the engineers here and we agree there may be an issue. It looks like we transition the connection we use to the non-transactional connection a bit too early. We transition as soon as we get the Optimistic Lock issue and we should likely wait for the afterCompletion callback. Please feel free to enter a bug. 

-Tom

Heider, Sabine wrote:

Hi Tom,


Could it be that EclipseLink switches to a non-transactional mode if

the PC is marked for rollback?

If that's the case, I would like to question that this behavior is

correct. (One could argue that it doesn't really matter which
connection is used for reading as the tx will be rolled back eventually
anyhow).

I am not sure the specification has any opinion about whether this
behavior is
correct, so I guess we have to figure out what we think is best.


I don't think either that the JPA spec says anything about it. I will have
a closer look at the JCA spec - maybe we can find something in there...
But yes, let's assume we have to figure out ourselves what should be done.


To me, the transaction is in rollback-only mode and therefore it is
probably not
correct to try to get transactional data.  Based on that assumption, I
think the
non-transactional read is probably as good a choice as we have
available.


I have quite a contrary understanding of the rollback-only mode. In my
opinion it is simply a marker that the transaction must eventually be
rolled back. In particular, the transaction is still in progress until
the rollback actually occurs.

I think that the application can expect the same level of connection sharing
with JPA as it would have if it accessed the data sources directly. That is,
it should end up with the same connection for the entire scope of the
transaction.
It seems also quite a valid assumption to me that the app should be able to see
uncommitted data that has been written within the same transaction, whether the
transaction is marked for rollback or not.

Best regards,
Sabine

Sabine Heider
SAP AG

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


-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-
bounces@xxxxxxxxxxx] On Behalf Of Tom Ware
Sent: Mittwoch, 9. Dezember 2009 16:39
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: AW: AW: [eclipselink-dev] Test
EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem
with JTA/non-JTA data sources

Hi Adrian,


Goerler, Adrian wrote:

Hi Tom,


- we need to check isOneServer before running the assert

I am actually, not sure I am understanding. Are you suggesting we

should skip the assert on #990 in case we are on server?

After looking further at this issue, I think we probably need to change
the
assert to somehow determine if the transaction is in rollback-only mode
in
another way.   I think the following would allow the test to pass, but
ideally
we would change the assertion in some other way.

if (!isOnServer){
                 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));
}

I cannot think of a way to test the transaction's state that will work
both in
JTA and non-JTA.  Can you?



- we should determine if the EE spec indicates what the expected

behavior is here, so we know if this is just a test bug, or if it
exposes an issue on NetWeaver.

Sabine observed that the flush (#980) is executed on a connection

obtained from the JTA data source while the query (#989) is executed on
a connection obtained from the non-JTA data source. It appears that
once the persistence context is marked for rollback only, EclipseLink
goes non-transactional. But the test asserts that EclipseLink hangs on
the transactional data source (sees the change on the transactional
data source).

Could it be that EclipseLink switches to a non-transactional mode if

the PC is marked for rollback?

If that's the case, I would like to question that this behavior is

correct. (One could argue that it doesn't really matter which
connection is used for reading as the tx will be rolled back eventually
anyhow).

I am not sure the specification has any opinion about whether this
behavior is
correct, so I guess we have to figure out what we think is best.

To me, the transaction is in rollback-only mode and therefore it is
probably not
correct to try to get transactional data.  Based on that assumption, I
think the
non-transactional read is probably as good a choice as we have
available.

Admittedly, in an extended persistence context the behavior is
inconsistent with
that assumption (since the assert passes in extended persistence
context) - we
do a non-transactional read that gets a cache hit that returns
uncommitted data.

The question I have is whether it is even reasonable for a user to to
write a
query in the rollback only state.  Based on that, I think we should
just fix the
assertion to do a better check if we can figure one out.

-Tom



-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 17:55
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re: AW: [eclipselink-dev] Test

EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem
with JTA/non-JTA data sources

Hi Adrian,

   The reason the test passes on other servers can be observed in the

comment:

987: // Query may fail in server as connection marked for rollback.

   Basically, in the server case, we do not get to the statement:

993: assertTrue("Failed to keep txn open for set RollbackOnly",
eName.equals(newName));

    Instead, an exception is thrown when we run the query and we get

to:

995: } catch (Exception ignore) {}

     The likely means the following:

- we need to check isOneServer before running the assert
- we should determine if the EE spec indicates what the expected

behavior is

here, so we know if this is just a test bug, or if it exposes an

issue on NetWeaver.

-Tom

Goerler, Adrian wrote:

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.EntityManagerJUnitTe
stSuite.testSetRollbackOnly(EntityManagerJUnitTestSuite.java:990)

   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
va:39)

   at

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
rImpl.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.runBareSe
rver(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(DelegatingMethodAccesso
rImpl.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.EntityManagerJUnitTe
stSuite.testSetRollbackOnly(EntityManagerJUnitTestSuite.java:994)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native

Method)

        at


sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
va:39)

        at


sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
rImpl.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.runBareSe
rver(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
_______________________________________________
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

_______________________________________________
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