Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316531

Summary: testRead() in LOB test model failed on WebSphere with NPE
Product: z_Archived Reporter: Yiping Zhao <yiping.zhao>
Component: EclipselinkAssignee: Project Inbox <eclipselink.orm-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: andrei.ilitchev, tom.ware
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Suggested patch. none

Description Yiping Zhao CLA 2010-06-10 16:29:31 EDT 
the test failed on WebLogic and GlassFish due to changes Andrei made on June 07 as fix of bug 244124, later Andrei fixed the error on June 9th. Actually at the same time, the test failed on WebSphere as well, but our nightly test result didn't expose it as new test failure, so we noticed the error later, the error message is:

<testcase classname="org.eclipse.persistence.testing.tests.jpa.lob.LobJUnitTestCase" name="testRead" time="10.188">
    <error type="java.lang.NullPointerException">java.lang.NullPointerException
	at org.eclipse.persistence.internal.helper.Helper.compareByteArrays(Helper.java:535)
	at org.eclipse.persistence.testing.tests.jpa.lob.LobJUnitTestCase.testRead(LobJUnitTestCase.java:128)
	at org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBareServer(JUnitTestCase.java:486)
	at org.eclipse.persistence.testing.framework.server.TestRunnerBean.runTest(TestRunnerBean.java:87)
	at org.eclipse.persistence.testing.framework.server.EJSRemote0SLTestRunner_ed643271.runTest(EJSRemote0SLTestRunner_ed643271.java)
	at org.eclipse.persistence.testing.framework.server._EJSRemote0SLTestRunner_ed643271_Tie.runTest(_EJSRemote0SLTestRunner_ed643271_Tie.java)
	at org.eclipse.persistence.testing.framework.server._EJSRemote0SLTestRunner_ed643271_Tie._invoke(_EJSRemote0SLTestRunner_ed643271_Tie.java)
	at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:622)
	at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:475)
	at com.ibm.rmi.iiop.ORB.process(ORB.java:504)
	at com.ibm.CORBA.iiop.ORB.process(ORB.java:1571)
	at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2771)
	at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2640)
	at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
	at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
	at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
</error>

Note: the test failed on 2.1 as well, since I don't know if we have time to fix the issue for 2.1 time frame, so I enter the bug as 2.2.0.
Comment 1 Andrei Ilitchev CLA 2010-06-15 14:31:45 EDT 
The test started to fail due to the change of the test code - it used to NOT close the entity manager before triggering the fetch group.
That means it's not a regression - to fix the test it should be just rolled back to its previous state (rev. 6213).

The test was altered to expose the bug, which happened when a fetch group is triggered on a detached object.
That bug was fixed as part of work on nested fetch groups (see bug 244124).
However this is still happening on WebSphere.

Investigation showed that on WebSphere after the entity manager is closed the object is still registered in the entity manager's unitOfWork (and the uow is not dead).

That is caused by fix to Bug 259993 - em.find() hangs up in some situations on WebSphere 7.0.0.1.

WebSphere apparently caches EntityNamagerImpls - instead of closing them it calls em.clear and then return to a cache for future reuse.
The problem was the timing of the clear call - it came when Eclipselink has not yet merged uow (in afterComplete).
Fix for Bug 259993 cured this problem but not allowing em.clear() called while uow is merging to do anything but to clear the cache.

There are several drawbacks to this solution:
1) Objects read in by ValueHolders triggered on detached objects may loose identity (uow has no cache);
2) uow is never released - map of clones, etc is held until the uow is garbage collected.

This second point is also the reason for the test failure - the fetch group code verifies if the object is registered in the uow, and if it is assumes that the object is also present in uow's cache.
But currently on WebSphere using jta after em.close() the object is still registered, but is not in the uow's cache.

The suggested solution: if em.clear is called on synchronized uow, and if the uow is merging (WebSphere's case) then don't clear the cache, but set the flag that will cause uow to be released after the merge in afterCompletion is complete.

That would cure both problems listed above.
Comment 2 Andrei Ilitchev CLA 2010-06-15 14:41:32 EDT 
Created attachment 171977 [details]
Suggested patch.
Comment 3 Andrei Ilitchev CLA 2010-06-15 16:27:38 EDT 
Checked into trunk. Reviewed by James. Will be backported to 2.1.1 when it's unfrozen.
Comment 4 Andrei Ilitchev CLA 2010-06-24 14:23:20 EDT 
Checked into 2.1.1
Comment 5 Eclipse Webmaster CLA 2022-06-09 10:02:50 EDT 
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink