Support Article
LockGoneException with container managed transaction processing
SA-1823
Summary
Developer was using Sonic Messenger Queue to send the Correlation ID value as pzInsKey of the work object to the dedicated MDB listener queue which calls the service rule. In service rule, service activity gets called and take a lock on the work object using the same and then call the ResumeFlow to process from the waiting assignment. Once ResumeFlow activity is done, call the Obj-Refresh-And-Lock and on next step Obj-Save Method.
Developer has noticed Obj-Refresh-And-Lock takes 60 seconds before timing out without getting back the lock. And, later it fails in the Obj-Save step due to LockGoneException.
Error Messages
2014-09-10 14:12:57,643 [stenerThreadPool : 0] [ STANDARD] [ DEMOFW:01.04.60] (Test.DEMO_Int_JMSMessage.Action) ERRORJMS|ReceiveResponse|ReceiveResponse|ReceiveResponse|A400D013F87C13B08C7696D921598D98B - obj-save failed.
com.pega.pegarules.pub.database.LockGoneException: Save, Delete or Commit has failed because lock "DEMO-FW-MCOM-WORK CO-54447" is not held
From: (A400D013F87C13B08C7696D921598D98B:ReceiveResponse)
Steps to Reproduce
- Create a Flow with two assignments shape.
- Create the work object (that executes the created Flow).
- On first assignment, work object gets assigned to a workbasket to get it processed by external transactional response.
- Create Service JMS, JMS MDB Listener and an activity to resume the Work Object from the waiting workbasket.
- Receive the response in the Service JMS from external system using JMS Queue.
- MDB listener creates requestor and executes the activity described in the Service JMS rule (the one created before). This activity opens the Work Object and take the lock on it using Obj-Open-by-Handle with the option lock and release on commit checked. Afterwards it calls the ResumeFlow activity to resume from the assignment on the waiting workbasket.
- After the resume is executed, the work object gets assigned to the next assignment.
- Once ResumeFlow is over, MDB listener's service rule activity next step will be called.
- Use Obj-Refresh-And-Lock to refresh a lock on the work object (lock has to be acquired since it has been lost in the commit of the ResumeFlow)
- Use Obj-Save method without commit option selected.
Root Cause
If container managed mode has been used in WebSphere, PRPC ignores any "Commit" or "Write-Now"; and operations were deferred until container completes the transaction.
Typically, when the activity methods that save or delete objects are used, they don’t cause the object to be saved or deleted immediately. Instead, these methods set up deferred write or deferred delete operations that are stored on a list of deferred operations. When a commit method is invoked and Process Commander is running in bean-managed mode, Process Commander completes all the tasks on the deferred operations list. When Process Commander is running in container-managed mode, commits are ignored.
With container-managed transactions, the transaction begins before Process Commander gets involved. The container begins a transaction that Process Commander participates in. When Process Commander is finished processing the request, any resulting operations are submitted to the resource manager. The commit or rollback operation occurs after the container considers all the operations from all the resource managers. If any of the participating applications marked the transaction for rollback, the transaction is rolled back.
Resolution
Suggested developer to implement ResumeFlow without Commit, which ensure the commit does not take place.
Published January 31, 2016 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.