[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: AW: [eclipselink-dev] Test EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with JTA/non-JTA data sources
|
Hi Tom,
> Please feel free to enter a bug.
Here you go:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=297558
Thanks,
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: Donnerstag, 10. Dezember 2009 16:10
An: Dev mailing list for Eclipse Persistence Services
Betreff: 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
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
