Database Table Commit/Data Integrity Issue

pureist

Suppose there are 2 Objects: O1 and O2.

O1 owns (multiple) O2.

A Process, P2, updates O2\Attribute A2 (which is a Reference Attribute (Peer Single) to another object) so as to be Defined or Undefined.

A Process, P1, runs immediately after P2, because P2 being run is a trigger for a HTML panel to be updated by P1.

Process P1 FIND's Object O1 then uses If.. Else If ..Else to determine what to do based on whether O2.A2 IS DEFINED (as modified by P2 a split second ago), which it obviously accesses via the Reference Attribute in O1 joining to O2.

Bug:
About 50% of the time P1 will do the wrong thing because the change made to O2.A2 by P2 a split second before P1 was run does not seem to be committed by the time P1 tests whether O2.A2 IS DEFINED via the Reference Attribute in O1 for O2.

Below is a summary of different outcomes which happen IF P1 does not do the correct thing according to the updated current defined status of 02.A2:

Even though P2 updated O2.A2 to be DEFINED, P1 completes the Actions associated with O2.A2 being UNDEFINED (as it was before being changed by P2 so as to be Defined a split second before).

OR
Even though P2 updated O2.A2 to be UNDEFINED, P1 completes the Actions associated with O2.A2 being DEFINED (as it was before being changed by P2 so as to be Undefined a split second before).

OR
Sometimes, it does both actions:

....a. First the actions associated with O2.A2's present (updated) defined status are carried out [CORRECT]; then,
....b. The actions associated with O2.A2's former defined status before P2 changed it a split second ago are carried out

Occasionally the application will hang (gray screen with hour glass) for about 10 seconds as if it is waiting for the Commit of O2.A2 to complete before a decision is made as to which action to proceed with.

....when the hanging ends, the outcome is either 1. or 2. above.

The first file in the attachment is the error message in the log which occurs when the application hangs.

The second file in the attachment is the log immediately following the incorrect action having been taken by P1, in which it appears that everything was executed correctly DESPITE the application displaying something entirely different on screen as to what the log indicated should be displayed).

Bizarrely this only happens in Chrome (with or without Cookies having been cleared), NOT Internet Explorer or Firefox, on Windows 10/64.

Please advise if a bug and I'll edit post and attach a bsv.

Aware Commit issue.zip

231.74kB

ACDC

Have you considered using the Rule Priority feature on the object

pureist

not sure what you mean in the context of how it applies to this scenario, where a process which is run separately (2nd) after the first process completes, carries out actions based on attribute values as they were before the first process was run.
could you please elaborate.

ACDC

It seems that P1 and P2 could be rules on the object when the object is either created or modified . The rule could eventually call the process to display the form. This way you can manage the rule priority (let the object rules do the heavy lifting) - that's if understand your application !

pureist

Thanks. But O2.A2's Defined status being set by P2 depends on a FIND whose criteria contains another attribute of O2 evaluated against those of another object, thus the save of O2 must be fully completed beforehand.
Thus P2 has to run after the form of O2 is saved, otherwise the system error will pop up 'a process has been started which requires input', or something of the sort.

A real life example of the bug would be to describe it as being like the value of the ShippedStatus attribute of an OrderLine object instance having been updated to 'Shipped', but a split second later another process evaluates the value of OrderLine.ShippedStatus for that instance by way of OrderHeader.Lines.ShippedStatus, and finds the value to still be 'Pending', and so it generates a duplicate shipment.

Bottom line is it only happens in Chrome, which would seemingly be a clue to resolving it.