Eclipse Community Forums: EclipseLink » Weird cache thread started

Help

Home

Home » Eclipse Projects » EclipseLink » Weird cache thread started(weblogic stacktrace in unknown thread)

Show: Today's Messages :: Show Polls :: Message Navigator

Weird cache thread started [message #978111]

Fri, 09 November 2012 21:14

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)

Report message to a moderator

Re: Weird cache thread started [message #981710 is a reply to message #978111]

Mon, 12 November 2012 16:34

Chris Delahunt

Messages: 1389
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

Report message to a moderator

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:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 20:24:18 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter