[JBPM-10249] Forcing dispose for command if transaction is not ready#2455
[JBPM-10249] Forcing dispose for command if transaction is not ready#2455fjtirado wants to merge 1 commit into
Conversation
| // check tx status to disallow dispose when within active transaction | ||
| TransactionManager tm = getTransactionManagerInternal(getEnvironment(runtime)); | ||
| if (tm.getStatus() != TransactionManager.STATUS_NO_TRANSACTION | ||
| if (!force && tm.getStatus() != TransactionManager.STATUS_NO_TRANSACTION |
There was a problem hiding this comment.
The whole purpose of the PR is to prevent this status check to avoid disposing on RuntimeManager created for a Disposable command if the status of the transaction is unknown/active.
There was a problem hiding this comment.
@fjtirado it is not clear what this PR is trying to resolve. Can you provide more information about the root cause? What happened that caused the timer service not to release the lock?
There was a problem hiding this comment.
@martinweiler This change is intended to ignore the transaction status when a dispose request is performed from a timer. Normally, the dispose request is ignored if the transaction status is not the desired one, but in the case of a timer I feel the transaction status is not relevant (because the timer is terminated for all practical purposes). So when a timer is done, I think the dispose should go through regardless of the transaction status (or we have the risk of the thread holding the lock forever, as it was apparently happening in the setup of the user reporting the issue)
There was a problem hiding this comment.
I've added some logging details to the jira https://issues.redhat.com/browse/RHPAM-5024 for your reference.
The root cause is not clear but is related to a transaction timeout. It looks to me when a transaction timeout occurs sometimes the transaction manager may not retrieve the right status.
|
jenkins retest this |
Thank you for submitting this pull request
JIRA:
link
referenced Pull Requests:
kiegroup/droolsjbpm-knowledge#651