Project

General

Profile

Bug #3031

FOR EACH can access shared transient records in case of broken transaction isolation

Added by Ovidiu Maxiniuc over 10 years ago. Updated over 10 years ago.

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

0%

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

Related issues

Related to Database - Feature #1851: database performance/scalability tuning New

History

#1 Updated by Ovidiu Maxiniuc over 10 years ago

In P4gl, if transaction isolation is broken, FOR EACH can access shared transient records that have fully matched their indexes.
I have added the uast/shared-dirty-records/leaking* procedures and data definition file to testcases repository. They are quite well documented and also contain the expected result from running them on 4GL.

After initialization and population of the table:
  • leaking1.p creates two records that will never be committed:
    • one (with id = 'NEW-ID') that doesn't break the isolation by not matching the index;
    • and one (with seq = 3) that gets shared among contexts.
  • the second procedure leaking2.p searched for both records and iterates all accessible records from table. We can notice that if the first procedure is not finished:
    • the NEW-ID record is isolated and I.e. not visible;
    • the seq = 3 record is visible in both direct FIND statement but also in FOR EACH looping query.

At this moment, P2J can see the second record by direct FIND -ing it, but will fail to retrieve the record in the FOR EACH loop. This is because the FOR EACH loop does not check the dirty database at all when creating the list of records to be processed.

Also available in: Atom PDF