Red Hat Bugzilla – Bug 832095
org.jbpm.process.audit.JPAWorkingMemoryDbLogger cannot lookup UserTransaction on Websphere appserver 7
Last modified: 2012-08-30 05:47:14 EDT
Description of problem: jBPM BAM module cannot log process execution events into database. Exception is thrown when JPAWorkingMemoryDbLogger tries to join a user transaction. The process instance execution doesn't seem to be affected. Version-Release number of selected component (if applicable): ER8 How reproducible: Steps to Reproduce: 1. deploy jBPM components into WAS7 2. run a simple process 3. see exception in server log Actual results: javaURLContex E NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J 2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not ex ecute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and theref ore is not supported by JNDI operations on "java:" names. Expected results: JPAWorkingMemoryDbLogger should be able to log process events. Additional info:
Created attachment 591836 [details] SystemOut.log Part of the server log containing exception stack trace.
Can you verify that inspite of the error, the event is still persisting in the database ? Similar situation occured with one of the EA participant. It is an unwanted error. The result is as expected whichis event is being persisted in the database, but still this error is thrown which is not valid. If that is true in your case too, I would put this in Release Notes and not fix the issue to remove the error in this release. If that is not true and the event is not being persisted, then we need to verify that.
From Kris: regarding https://bugzilla.redhat.com/show_bug.cgi?id=832095 that seems to happen if you are running in a non-JTA environment (probably spring with local transactions) 11:58 this is what I sent david yesterday: as part of the JPAWorkingMemoryDbLogger, it's trying to figure out it needs to start a transaction (which is only necessary if you want to use this logger in combination with a ksession that does not use persistence). It does so by trying to look up a user transaction in jndi. In this case, it's failing to initialize the jndi context. But this is not a problem, as spring is already managing the transaction. I guess this can be solved by: - creating a jdni.properties file that specifies which JNDI factory to use - using a customized version of the logger that does not include the JNDI lookup (which might be more performant I think in this case) 11:59 so the error doesn't indicate an issue, and could be avoided by registering a custom logger when using local spring I suppose
This only happens in a situation where you are not using JTA (so basically Spring + resource local, as other configurations are not supported). JPAWorkingMemory tries to look up the JTA transaction by default (to determine it needs to start a new transaction or not). This fails in you're not in a JTA environment (and writes out the issue to sysout), but the service continues without starting a new transaction in this case (which is the correct behavior). So it seems in this situation the error message is shown but the service is working correctly. To avoid the exception, users could register their own implementation that does not do this (which could be documented and doesn't require any code changes). I've changed this on master so it doesn't write the exception to sysout (so the logger can be configured to hide this warning for example).