Loading...

XML

Word

Printable

Steps to Reproduce:

Hide

1. Deploy application from attached archive (build/testApp.ear) to the server.
2. Open /test/testCache1.jsp page.
3. Click on 'Perform test' link.
Expected result: "Test finished." message is shown after about 10 seconds. No errors is shown.
Actual result: Exception "java.rmi.RemoteException: Invocation failed; nested exception is: javax.ejb.EJBException: java.lang.IllegalArgumentException: Instance for PK [test_pk] already registerd." is shown.

Please note, this syntetic test case works only if Infinite pool is used for entity beans (which is the only option as for 7.1CR), as it uses artifical wait in 'setEntityContext' method of test bean to put both threads into the same execution point.

Show
1. Deploy application from attached archive (build/testApp.ear) to the server. 2. Open /test/testCache1.jsp page. 3. Click on 'Perform test' link. Expected result: "Test finished." message is shown after about 10 seconds. No errors is shown. Actual result: Exception "java.rmi.RemoteException: Invocation failed; nested exception is: javax.ejb.EJBException: java.lang.IllegalArgumentException: Instance for PK [test_pk] already registerd." is shown. Please note, this syntetic test case works only if Infinite pool is used for entity beans (which is the only option as for 7.1CR), as it uses artifical wait in 'setEntityContext' method of test bean to put both threads into the same execution point.

While running multithreaded workload against AS 7.1Beta/CR1 for application with Entity EJB 2.x we've faced a lot of following errors:

It seems, that these errors are caused by synchronization issues in ReferenceCountingEntityCache:

If two threads are trying to access the cache and there is no ready instance for particular PK in the cache, then both threads are trying to get some instance from the pool and put it into the cache – as result, the second thread can get 'already registered' exception. We were able to compose a minimal test case application which reproduces this kind of problem (see below).
There is a gap in time between the call to Associate interceptor (which puts instance in cache - via 'get' method) and Synchronization interceptor (which calls 'reference' method). During this time instance is not referenced, so it seems it can be removed by some other thread which finish its invocation at the same time. Probably this is the root cause of 'not found in cache' error, however it's hard to create a syntetic test case for it.