Bug 832095
| Summary: | org.jbpm.process.audit.JPAWorkingMemoryDbLogger cannot lookup UserTransaction on Websphere appserver 7 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Jiri Locker <jlocker> | ||||
| Component: | jBPM Console | Assignee: | Kris Verlaenen <kverlaen> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | BRMS 5.3.0.GA | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: |
IBM Websphere Application Server 7.0.0.0
|
|||||
| Last Closed: | 2025-02-10 03:20:06 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Jiri Locker
2012-06-14 13:46:23 UTC
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). This product has been discontinued or is no longer tracked in Red Hat Bugzilla. |