[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipselink-dev] Fix for bug# 259993 - [branch 1.1] WebSphere 7 em.clear() callback within commit causes a subsequent em.find() to hang
|
Sebastien,
Yes, I am waiting for the official run on all application servers and mysql.
I ran the full JPA, Core and WebSphere LRGs against an Oracle DB.
Thank you
/michael
----------Original Message----------
From: "Sebastien Tardif" <stardif@xxxxxxxxxxxx>
Sent: Fri, February 13, 2009 12:07 PM
To: "Dev mailing list for Eclipse Persistence Services" <eclipselink-dev@xxxxxxxxxxx>
Subject: RE: [eclipselink-dev] Fix for bug# 259993 - [branch 1.1] WebSphere 7 em.clear() callback within commit causes a subsequent em.find() to hang
The changes don't look trivial to me, so are we going to rerun all the
tests against this new code before releasing EclipseLink 1.1?
Maybe it's always the case when a new RC(RC2?) is created.
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael
O'Brien
Sent: Thursday, February 12, 2009 3:37 PM
To: eclipselink-dev@xxxxxxxxxxx
Subject: [eclipselink-dev] Fix for bug# 259993 - [branch 1.1] WebSphere
7 em.clear() callback within commit causes a subsequent em.find() to
hang
Developers,
The following fix has been reviewed and checked into the EclipseLink
1.1 branch under rev# 3447.
http://bugs.eclipse.org/259993
https://bugs.eclipse.org/bugs/attachment.cgi?id=125455&action=diff
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=3447
Code Review: Thank you
Gordon Yorke, Andrei Ilitchev, James Sutherland
Cause:
On WebSphere 7 we hang on a find() after a commit().
A WebSphere 7.0 (6.1 is ok) em.close() callback in the middle of
a commit() is causing the entityManager state to be reset before the
transaction completes.
The result of this is that we end up having pending changes that
should have been commited but when committed during ReadObjectQuery on a
em.find() for example - when we attempt to get a lock - we are blocked
by the previous acquire() that did not release() because of the WAS
em.close() that reset our UnitOfWork state - mid transaction.
RepeatableWriteUnitOfWork.clearForClose(boolean)
line:126
EntityManagerImpl.clear() line: 220
JPAEMPool.putEntityManager(EntityManager) line:
147
JPATxEntityManager.closeTxEntityManager(EntityManager,boolean) line:
299
Fix:
Fully clear the entityManager "only" when we are in a non
*Pending state/lifecycle - in which case we only clear the cache - not
the em state.
Reproduction:
1 - container manged stateless session bean running on WebSphere
7.0
2 - persist() and commit() a single entity
2a - we acquire locks in beforeCompletion()
2b - during the commit() but before afterCompletion() - WebSphere
calls em.close() which calls uow.clearForClose()
- it is here that we clear the em and set the
state/lifecycle back to 0 (Birth) from 4 (*Pending)
Details of the fix:
EclipseLink on WebSphere 7.0 is supported.
Part 1) uow.clearForClose()
- we do not fully clear the em on a clear() call unless the
state/lifecycle of the entityManager is 0,3,5 or 6, if the
state/lifecycle is 1,2 or 4 (*Pending) we only clear the cache.
- the em state remains uncleared, the afterCompletion code in
the transaction commits normally.
Part 2) uow.mergeClonesAfterCompletion()
- added code to save the current thread on acquire
- on a merge we check that the current thread and the current
thread on the previous acquire are equal - if they are not then we
overwrite the active thread on the mutex on all acquired locks in the
mergeManager
Test Results:
(All tests run on the IBM J9 JVM shipped with WebSphere 7.0)
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows Vista x86-32
jvmwi3260-20080816_22093
1.1 (with local db clean)
New tests in jpa/advanced/concurrency/LifecycleJUnitTest
JPA LRG
Without fix (- expected errors on new LifecycleJUnitTest
suite if fix is disabled)
[junit] Tests run: 1071, Failures: 0, Errors: 3, Time
elapsed: 896.499 sec
With fix
[junit] Tests run: 1071, Failures: 0, Errors: 3, Time
elapsed: 935.753 sec
Core LRG
With/Without fix
[junit] Tests run: 6647, Failures: 0, Errors: 0, Time
elapsed: 1,523.895 sec
WebSphere server tests
Where previously we hung on the following suites, we now get
the same results as WebSphere 6.1
[junit] Running
org.eclipse.persistence.testing.tests.jpa.relationships.ServerTestSuite
[junit] Tests run: 30, Failures: 0, Errors: 0, Time
elapsed: 98.124 sec
[junit] Running
org.eclipse.persistence.testing.tests.jpa.fieldaccess.advanced.ServerTes
tSuite
[junit] Tests run: 203, Failures: 0, Errors: 2, Time
elapsed: 162.483 sec
>ant server-test-lrg
WebSphere 7.0
Total time: 35 minutes 11 seconds
1045 0 28 97.32% 508.332
Name Tests Errors Failures Time(s) Time Stamp Host
org.eclipse.persistence.testing.tests.jpa.advanced 248 6 0 94.782
2009-02-12T19:31:08 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.datatypes 17 0 0 4.399
2009-02-12T19:32:41 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.datetime 7 0 0 2.943
2009-02-12T19:34:03 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.ddlgeneration 9 1 0 6.633
2009-02-12T19:35:26 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.fieldaccess.advanced 203 2 0
95.392 2009-02-12T19:36:56 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.fieldaccess.relationships 16 0
0 12.135 2009-02-12T19:40:01 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.inheritance 41 1 0 35.441
2009-02-12T19:41:37 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.inherited 51 1 0 12.866
2009-02-12T19:43:37 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.jpaadvancedproperties 10 10 0
2.628 2009-02-12T19:45:13 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.jpql 273 0 0 145.442
2009-02-12T19:46:44 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.lob 5 1 0 2.145
2009-02-12T19:50:38 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.relationships 30 0 0 49.495
2009-02-12T19:52:07 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.sessionbean 5 2 0 8.675
2009-02-12T19:54:27 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.timestamptz 5 0 0 1.758
2009-02-12T20:01:47 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.validation 3 0 0 3.767
2009-02-12T19:56:01 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.xml 108 4 0 23.578
2009-02-12T19:59:38 mfobrien-PC3
org.eclipse.persistence.testing.tests.jpa.xml.merge.inherited 14 0 0
6.253 2009-02-12T19:57:46 mfobrien-PC3
>results: we have the same # of total errors+failures (28 instead of
27) but they are all errors in WAS 7.0
All but one of these failure to error transitions are due to new
serialization requirements on WAS...
testVersionUpdateWithIncorrectValue
in WebSphere 6.1 is
Failure: updating object version with wrong value threw a wrong
exception: javax.transaction.RollbackException
In WebSphere 7.0 is
Error: CORBA MARSHAL 0x4942f896 No; nested exception is:
org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge :
Mismatched serialization UIDs
WebSphere 6.1 (for comparison)
http://stame02.us.oracle.com/eclipselink/1.1.0-release/2009-02-10/server
-test-lrg-websphere-6.1.html
1045 6 21 97.42% 544.358
Name Tests Errors Failures Time(s) Time Stamp Host
org.eclipse.persistence.testing.tests.jpa.advanced 248 3 2 79.121
2009-02-10T20:14:20 stame10
org.eclipse.persistence.testing.tests.jpa.datatypes 17 0 0 5.182
2009-02-10T20:15:57 stame10
org.eclipse.persistence.testing.tests.jpa.datetime 7 0 0 3.400
2009-02-10T20:17:25 stame10
org.eclipse.persistence.testing.tests.jpa.ddlgeneration 9 1 0 8.118
2009-02-10T20:19:02 stame10
org.eclipse.persistence.testing.tests.jpa.fieldaccess.advanced 203 0 2
104.429 2009-02-10T20:20:38 stame10
org.eclipse.persistence.testing.tests.jpa.fieldaccess.relationships 16 0
0 15.935 2009-02-10T20:23:48 stame10
org.eclipse.persistence.testing.tests.jpa.inheritance 41 0 1 41.463
2009-02-10T20:25:34 stame10
org.eclipse.persistence.testing.tests.jpa.inherited 51 0 1 22.055
2009-02-10T20:27:41 stame10
org.eclipse.persistence.testing.tests.jpa.jpaadvancedproperties 10 10 0
5.170 2009-02-10T20:29:32 stame10
org.eclipse.persistence.testing.tests.jpa.jpql 273 0 0 139.433
2009-02-10T20:31:06 stame10
org.eclipse.persistence.testing.tests.jpa.lob 5 1 0 4.359
2009-02-10T20:34:50 stame10
org.eclipse.persistence.testing.tests.jpa.relationships 30 0 0 48.656
2009-02-10T20:36:19 stame10
org.eclipse.persistence.testing.tests.jpa.sessionbean 5 2 0 13.413
2009-02-10T20:38:33 stame10
org.eclipse.persistence.testing.tests.jpa.timestamptz 5 0 0 3.860
2009-02-10T20:45:40 stame10
org.eclipse.persistence.testing.tests.jpa.validation 3 0 0 6.590
2009-02-10T20:40:14 stame10
org.eclipse.persistence.testing.tests.jpa.xml 108 4 0 33.863
2009-02-10T20:43:42 stame10
org.eclipse.persistence.testing.tests.jpa.xml.merge.inherited 14 0 0
9.311 2009-02-10T20:41:52 stame10
thank you
/michael
_______________________________________________
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
