Feedback
Did this article resolve your question/issue?

   

Article

Transaction not completely rolled back when more than 65,536 sub-transactions

« Go Back

Information

 
TitleTransaction not completely rolled back when more than 65,536 sub-transactions
URL Name000036325
Article Number000164548
EnvironmentProduct: OpenEdge
Version: 10.x, 11.0, 11.1
OS: All supported platforms
Question/Problem Description
When a transaction containing more than 65,536 sub-transactions, is undone, the transaction is not completely rolled back. 
The first 65,536 sub-transactions are not rolled back at all; the remaining sub-transactions are rolled back correctly.

 
Steps to Reproduce
Clarifying Information

Attached is a test case demonstrating the issue. OE00225722.zip

  • Unzip the files to working directory
  • Load the .df and .d into a test database
  • Run the testprocedure.p while connected to this test database.

The procedure will create 2 dump files:

  1. Before the update and
  2. After undoing a transaction that updates all records in a table.

The dumps will not be identical in size.
Further comparison will show that changes to the first 65536 records have not been undone.

Also included in OE00225722.zip is a procedure "countsubtrans.p". This can parse the 4GLTrans client logging to determine how many subtransactions are started within a transaction. To get the log file to parse, start the OpenEdge client with parameters: -clientlog Trans.log -logentrytypes 4GLTrans:4

Error Message
Defect NumberDefect PSC00248436 / OE00225722
Enhancement Number
Cause
A savepoint is stored in an internal location that is not long enough to hold it.
Resolution
Upgrade to OpenEdge 11.2 or 11.3. 
Upgrade to OpenEdge 10.2B08.

If this issue is encountered in environment where multiple databases are connected to when sub-transactions are undone and error 1422 results, please refer to Article  Index corruption undoing sub-transactions when multiple logical databases are connected    
Workaround
When possible, avoid creating a single large transaction with many sub-transactions. In addition to avoiding defect OE00225722, this will provide greater concurrency by locking no more records than necessary for no longer time than necessary.
Notes
References to Other Documentation:

OpenEdge Getting Started: ABL Essentials, Chapter 10, "Managing Transactions > Controlling the size of a transaction"
Last Modified Date7/16/2021 9:08 PM
Attachment 
Files 1. OE00225722.zip
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.