Bug 832095 - org.jbpm.process.audit.JPAWorkingMemoryDbLogger cannot lookup UserTransaction on Websphere appserver 7
org.jbpm.process.audit.JPAWorkingMemoryDbLogger cannot lookup UserTransaction...
Status: ASSIGNED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM Console (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Maciej Swiderski
Jiri Locker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-14 09:46 EDT by Jiri Locker
Modified: 2012-08-30 05:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
IBM Websphere Application Server 7.0.0.0
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SystemOut.log (18.37 KB, text/plain)
2012-06-14 09:56 EDT, Jiri Locker
no flags Details

  None (edit)
Description Jiri Locker 2012-06-14 09:46:23 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:
Comment 1 Jiri Locker 2012-06-14 09:56:23 EDT
Created attachment 591836 [details]
SystemOut.log

Part of the server log containing exception stack trace.
Comment 2 Prakash Aradhya 2012-06-14 11:26:26 EDT
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.
Comment 3 Prakash Aradhya 2012-06-14 12:21:36 EDT
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
Comment 4 Kris Verlaenen 2012-06-14 16:39:50 EDT
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).

Note You need to log in before you can comment on or make changes to this bug.