[jBPM] - Re: Session and thread safety
by Sebastian Calbaza
Sebastian Calbaza [https://community.jboss.org/people/calbazasebastian] created the discussion
"Re: Session and thread safety"
To view the discussion, visit: https://community.jboss.org/message/760010#760010
--------------------------------------------------------------
Here is my thread safe ProcessPersistenceContextManager if someone needs it.
It needs to be set on the Environment param (env.set(EnvironmentName.PERSISTENCE_CONTEXT_MANAGER, persistenceContextManager);) before you pass it to JPAKnowledgeService.newStatefulKnowledgeSession(kbase,null, env)
-----------------------------------------
public class MyJpaProcessPersistenceContextManager implements
ProcessPersistenceContextManager, PersistenceContextManager {
private EntityManagerFactory emf;
private ThreadLocal<EntityManager> appScopedEntityManager=new ThreadLocal<EntityManager>();
protected ThreadLocal<EntityManager> cmdScopedEntityManager=new ThreadLocal<EntityManager>();
public ProcessPersistenceContext getProcessPersistenceContext() {
return new JpaProcessPersistenceContext(cmdScopedEntityManager.get());
}
public MyJpaProcessPersistenceContextManager(Environment env) {
this.emf = (EntityManagerFactory) env.get(EnvironmentName.ENTITY_MANAGER_FACTORY);
}
public PersistenceContext getApplicationScopedPersistenceContext() {
if (this.appScopedEntityManager.get() == null) {
this.appScopedEntityManager.set(this.emf.createEntityManager());
}
return new JpaPersistenceContext(appScopedEntityManager.get());
}
public PersistenceContext getCommandScopedPersistenceContext() {
return new JpaPersistenceContext(this.cmdScopedEntityManager.get());
}
public void beginCommandScopedEntityManager() {
if (cmdScopedEntityManager.get() == null ||
(this.cmdScopedEntityManager.get() != null && !this.cmdScopedEntityManager.get().isOpen())) {
this.cmdScopedEntityManager.set( this.emf.createEntityManager());
}
cmdScopedEntityManager.get().joinTransaction();
appScopedEntityManager.get().joinTransaction();
}
public void endCommandScopedEntityManager() {
if (this.cmdScopedEntityManager.get()!=null){
this.cmdScopedEntityManager.get().flush();
this.cmdScopedEntityManager.get().close();
}
}
public ThreadLocal<EntityManager> getCmdScopedEntityManager() {
return cmdScopedEntityManager;
}
public ThreadLocal<EntityManager> getAppScopedEntityManager() {
return appScopedEntityManager;
}
public void dispose() {
if (this.appScopedEntityManager.get() != null && this.appScopedEntityManager.get().isOpen()) {
this.appScopedEntityManager.get().flush();
this.appScopedEntityManager.get().close();
}
this.appScopedEntityManager.set(null);
if (this.cmdScopedEntityManager.get() != null && this.cmdScopedEntityManager.get().isOpen()) {
this.cmdScopedEntityManager.get().flush();
this.cmdScopedEntityManager.get().close();
}
this.cmdScopedEntityManager.set(null);
}
}
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/760010#760010]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 1 month
[JBoss Tools] - JBoss 4.1.0.Alpha1 memory leak?
by Jesper Skov
Jesper Skov [https://community.jboss.org/people/jskovjyskebankdk] created the discussion
"JBoss 4.1.0.Alpha1 memory leak?"
To view the discussion, visit: https://community.jboss.org/message/804026#804026
--------------------------------------------------------------
A few of us has started using the new Alpha1 with Kepler M5.
The impression is there is a much higher memory load. Especially on XP where our Heap is limited to 1GB this becomes a problem.
Since I don't have a specific use case I can repeat, I have a little trouble providing you with some useful information.
However, I got a heap dump from one of the sessions where things was at a crawl. Analyzing it, I find this in Memory Analysis's leak suspects:
900 instances of *"org.jboss.tools.common.model.filesystems.impl.JarAccess"*, loaded by *"org.jboss.tools.common.model"* occupy *68.321.856 (18,11%)* bytes.
These instances are referenced from one instance of *"org.eclipse.jdt.core.IElementChangedListener[]"*, loaded by *"org.eclipse.jdt.core"*
20% of memory locked up by a single plugin seems excessive, but I don't really have anything to compare it with. So it may be OK?!?
What do you think?
Is there something I can provide you to resolve if this is a JBossTools leak?
Cheers,
Jesper
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/804026#804026]
Start a new discussion in JBoss Tools at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 1 month
