Skip to main content
[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 
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

Back to the top