Feedback
Did this article resolve your question/issue?

   

Article

What does a transaction state of DEAD or NONE mean in PROMON?

Information

 
TitleWhat does a transaction state of DEAD or NONE mean in PROMON?
URL NameP133138
Article Number000128552
EnvironmentProduct: Progress
Versions: All supported versions
Product: OpenEdge
Versions: All supported versions
OS: All supported platforms
Question/Problem Description
What does a transaction state DEAD or NONE mean in PROMON?
When does PROMON show transaction state DEAD or NONE?
How can a process have locked records with a DEAD transaction?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
Within the PROMON Option 4 Record Locking Table results, a transaction may occasionally be listed with a Transaction State of dead.  
  • When the "Tran State" is DEAD it signifies the transaction is no longer active. The transaction was either committed or rolled back.
  • When the transaction id is listed, it is the one that existed previously when the transaction was active but no longer is active. 
  • Effectively, It means that the transaction table entry previously held is now free and available for reuse by a new transaction.  
  • In later OpenEdge 11 releases, transaction state "Dead" was renamed to "None".

Example:

Record Locking Table:
Usr Name     Chain #      Rec-id Table Lock Flags Tran State Tran ID
 24 usr      REC  9410  19629915   121 SHR        Dead             0
 47 usr      REC  9528  19616970   121 SHR        Dead             0
 35 usr      REC  9528  19616970   121 SHR        Dead             0
 32 usr      REC  9528  19616970   121 SHR        Dead             0
 31 usr      REC  9528  19616970   121 SHR        Dead             0
 24 usr      REC  9744  19629916   454 SHR        Dead         62834
 39 usr      REC  9770  19630275   121 SHR        Dead             0
 30 usr      REC  9772  19630277   121 SHR        Dead   



DEAD Transaction states can often occur when record locks (in particular SHARE LOCKS) are acquired outside of a transaction, possibly due to record and/or buffer scoping issues.

As an example:  The following snippets of code can be run against a sports2000 database to demonstrate a DEAD transaction locking a record.

1.  Create a sports2000 database:  prodb sports2000 sports2000
2.  Start the database:  proserve sports2000
3.  Create a file that contains the following code and call it: dead1.p
DO TRANSACTION:
    FIND FIRST customer EXCLUSIVE.
    ASSIGN balance = balance + 1.
END.

DO:
    FIND FIRST customer SHARE-LOCK. /* this triggers the "dead" transaction */
    DISP custnum name balance.
    PAUSE.
END.
4.  Create another file that contains the following code and call it: dead2.p.
FIND FIRST customer EXCLUSIVE-LOCK.

5.  Start a client running the first program:  mpro sports2000 -p dead1.p
6.  Start a second client running the second program:  mpro sports2000 -p dead2.p
7.  Access PROMON and look at the Record Locking table:  promon sports2000 -> 4.  Record Locking Table -> 1.  Display all processes.


Record Locking Table:                                                
Usr Name     Chain #      Rec-id Table Lock Flags  Tran State Tran ID
  5 usr      REC   195       193     2 SHR         Dead             0
  6 usr      REC   195       193     2 EXCL   Q H  Begin         1482

 
Workaround
Notes
Last Modified Date11/20/2020 7:25 AM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.