Project

General

Profile

Bug #11810

READ-JSON transaction scope leak

Added by Teodor Gorghe 2 days ago. Updated about 22 hours ago.

Status:
Internal Test
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
Ovidiu Maxiniuc
production:
No
env_name:
topics:

History

#1 Updated by Teodor Gorghe 2 days ago

Testcase:

Cause: when READ-JSON returns false, the JsonImporter doesn't commit/rollback the transaction when READ-JSON is not currently in full transaction. The session inTx remains true, which abends on DO TRANSACTION block when beginning a transaction.

#2 Updated by Ovidiu Maxiniuc 2 days ago

I think temp-table tt1:read-json() should be run inside a micro-transaction if none is already open. The pattern we use in such cases should close the transaction before the method returns. Secondary note: methods return No logical value instead of 'hard-stopping' the current block.

I scanned the json/xml readers and all seem to rely on transactions being already open and closed by an outer procedure.

#3 Updated by Constantin Asofiei 2 days ago

I think Paul did some changes related to micro-transactions and datasets with relations - maybe this bug comes from there.

Ovidiu: your note to use a full tx (if not already open) works only and only if 4GL does not leave behind already imported records, from before any error is encountered.

#4 Updated by Teodor Gorghe 2 days ago

Constantin Asofiei wrote:

I think Paul did some changes related to micro-transactions and datasets with relations - maybe this bug comes from there.

Ovidiu: your note to use a full tx (if not already open) works only and only if 4GL does not leave behind already imported records, from before any error is encountered.

I know, I have some changes which I will commit in 11810a.

#5 Updated by Ovidiu Maxiniuc 1 day ago

Wait, wait, wait... Now it is coming back to me...

We have already this in trunk since r16566. One of the changes was to add/fix transactional reads from JSON files. The prepareTopLevel(), beginTopLevel, rollbackTopLevel, and commitTopLevel() from JsonImport do the transaction management driven by top-level records from the JSON input. When a top-level record is processed a new micro-transaction is opened (beginTopLevel() will check the transaction status and create a new savepoint if already in a transaction).

I think this is one of the testcases (a case of malformed JSON) which we fail to test in r16566. Reading the first record will cause the uTransaction to be open by beginTopLevel(), but the JSON syntax error did not triggered the rollbackTopLevel() so that the transaction remained open.

This is pure theoretical, it needs to be confirmed by debugging the testcase listed in 1st note.

#6 Updated by Teodor Gorghe 1 day ago

  • Status changed from New to WIP
  • % Done changed from 0 to 100
  • reviewer Ovidiu Maxiniuc added

Yes, but this is the case when rollbackTopLevel or commitTopLevel doesn't get executed, which leads to session inTx = true flag set after READ-JSON execution.
Check 11810a/r16731.

#7 Updated by Teodor Gorghe 1 day ago

  • Status changed from WIP to Review

#8 Updated by Ovidiu Maxiniuc 1 day ago

  • Status changed from Review to Internal Test

I think 11810a/r16731 is good. 👍

#9 Updated by Teodor Gorghe about 22 hours ago

Tested on all projects which uses READ-JSON and testing has passed.

Also available in: Atom PDF