Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Weird cache thread started(weblogic stacktrace in unknown thread)
Weird cache thread started [message #978111] Fri, 09 November 2012 16:14 Go to next message
Missing name Missing name is currently offline Missing name Missing name
Messages: 1
Registered: November 2012
Junior Member
Hi

We use a threadlocal variabel in our mdb in weblogic 12c, but suddenly see a new thread started up which fails as it haven't set our threadlocal variabel used in the init of our entityclass (used for setting userinfo) and our code raises an exception.
When disabling L2 cache this thread isn't appearing, so seems there is multi-threading involved in L2 caching and what is it's job ??

any idea how to fix this - other than disabling L2 cache ?

Regards
Mejar

Stacktrace is:

2012-11-08 13:30:18,681 ERROR [[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] ...wmdata.egf.security.ActiveUser - com.wmdata.egf.util.EgfException: EgfUser unknown to this thread
at com.wmdata.egf.security.ActiveUser.get(ActiveUser.java:56)
at com.wmdata.egf.security.ActiveUser.getUserId(ActiveUser.java:62)
at com.wmdata.examdb.entity.CreateUpdateMetadata.<init>(CreateUpdateMetadata.java:33)
at com.wmdata.examdb.entity.StatusReportEntity.<init>(StatusReportEntity.java:14)
at sun.reflect.GeneratedConstructorAccessor170.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.eclipse.persistence.internal.descriptors.InstantiationPolicy.buildNewInstanceUsingDefaultConstructor(InstantiationPolicy.java:132)
at org.eclipse.persistence.internal.descriptors.InstantiationPolicy.buildNewInstance(InstantiationPolicy.java:103)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildNewInstance(ObjectBuilder.java:547)
at org.eclipse.persistence.descriptors.copying.InstantiationCopyPolicy.buildClone(InstantiationCopyPolicy.java:31)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.instantiateClone(ObjectBuilder.java:3322)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.buildOriginal(UnitOfWorkImpl.java:571)
at org.eclipse.persistence.internal.sessions.MergeManager.mergeChangesOfWorkingCopyIntoOriginal(MergeManager.java:687)
at org.eclipse.persistence.internal.sessions.MergeManager.mergeChangesOfWorkingCopyIntoOriginal(MergeManager.java:617)
at org.eclipse.persistence.internal.sessions.MergeManager.mergeChanges(MergeManager.java:267)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.mergeChangesIntoParent(UnitOfWorkImpl.java:3254)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.mergeChangesIntoParent(RepeatableWriteUnitOfWork.java:370)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.mergeClonesAfterCompletion(UnitOfWorkImpl.java:3386)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.afterCompletion(AbstractSynchronizationListener.java:213)
at org.eclipse.persistence.transaction.JTASynchronizationListener.afterCompletion(JTASynchronizationListener.java:79)
at weblogic.transaction.internal.ServerSCInfo.doAfterCompletion(ServerSCInfo.java:1068)
at weblogic.transaction.internal.ServerSCInfo.callAfterCompletions(ServerSCInfo.java:1031)
at weblogic.transaction.internal.ServerTransactionImpl.callAfterCompletions(ServerTransactionImpl.java:3074)
at weblogic.transaction.internal.ServerTransactionImpl.afterCommittedStateHousekeeping(ServerTransactionImpl.java:2972)
at weblogic.transaction.internal.ServerTransactionImpl.setCommittedUnsync(ServerTransactionImpl.java:3023)
at weblogic.transaction.internal.ServerTransactionImpl.ackCommit(ServerTransactionImpl.java:1169)
at weblogic.transaction.internal.CoordinatorImpl.ackCommit(CoordinatorImpl.java:290)
at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:693)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:518)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:514)
at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
Re: Weird cache thread started [message #981710 is a reply to message #978111] Mon, 12 November 2012 11:34 Go to previous message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
WebLogic uses a seperate thread to manage transactional resources, and this thread ends up calling the afterCompletion method that handles merging into the shared cache and cleaning up JPA resources. I don't know of a way or setting to stop this from being done in a seperate thread, but you may want to check the WebLogic docs or contact WebLogic support.

An EclipseLink solution might be to handle setting/unsetting of the value in the thread using UnitOfWork events listed here:
http://wiki.eclipse.org/Introduction_to_EclipseLink_Sessions_(ELUG)#Managing_Session_Events_with_the_Session_Event_Manager
Registering a SessionEventListener, and then storing the value in the UnitOfWork's properties in a PostAcquireUnitOfWork event method, then setting it on your thread context in PreMergeUnitOfWorkChangeSet and PreDistributedMergeUnitOfWorkChangeSet (if using RCM to send changes out to remote caches).

Best Regards,
Chris
Previous Topic:JPA 2 inserting Parent table when trying to update child table field
Next Topic:JPQL Bug? BigInteger 22 digits (precision=22, scale=0)
Goto Forum:
  


Current Time: Fri Jul 25 14:36:26 EDT 2014

Powered by FUDForum. Page generated in 0.01674 seconds