FWD » Core Development » Base Language

Implement the following:

• TRANSACTION handle-based resource
• SET-COMMIT method
• SET-ROLLBACK method
• TRANSACTION-MODE-AUTOMATIC statement

According to this https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop/automatic-transaction-example.html, RUN ... TRANSACTION DISTINCT might relate to the TRANSACTION-MODE AUTOMATIC statement.

I'll need some tests to see how this is needed.

• IS-OPEN attribute should be easy to add, as is the same as the TRANSACTION function
• DEFAULT-COMMIT requires more testing, to see how it behaves (it might be easy, just commit the transaction if one is opened)
• TRANS-INIT-PROCEDURE should be easy, just save the handle of the procedure which initiated the transaction

There is also the TRANSACTION-MODE AUTOMATIC CHAINED version of the statement, where CHAINED (according to docs) just re-starts the transaction after the set-commit() or set-rollback() call.

And another note about RUN ... TRANSACTION DISTINCT - can you check the reports if this RUN statement option is used in current project?

Further reading shows that RUN ... TRANSACTION DISTINCT is used as a fail-safe if 4GL decides to propagate the client's transaction to the AppServer side, sometime in the future. So looks like currently this is a no-op in 4GL.

Go ahead and add these other features.

And another note about RUN ... TRANSACTION DISTINCT - can you check the reports if this RUN statement option is used in current project?

Yes, it is heavily used.

Further reading shows that RUN ... TRANSACTION DISTINCT is used as a fail-safe if 4GL decides to propagate the client's transaction to the AppServer side, sometime in the future. So looks like currently this is a no-op in 4GL.

PLease run testcases to confirm. If it is a NO-OP, it is surprising it shows up so often in the code.

At a minimum we need to handle the conversion side.

Is it OK to use TransactionManager.transactionModeAuto() for TRANSACTION-MODE AUTO statement?

Constantin Asofiei wrote:

Is it OK to use TransactionManager.transactionModeAuto() for TRANSACTION-MODE AUTO statement?

Actually, this sets a procedure-specific flag, so I'll use ProcedureManager.

Yes, that is fine.

• this is accessed via procedure:TRANSACTION, and (at least in non-appserver mode), one would think that this object is specific for the procedure - but it is not, it is global, any procedure returns the same handle for TRANSACTION attribute.
• if you try to delete this handle, a subsequent access will recreate the handle (and be reported as valid), but accessing any of its state results in a TRANSACTION context object not available. (7354) error.
• and, trying to delete the handle again, will result in a 4GL abend.

Created task branch 3754a from trunk rev 11289.

Rev 11290 adds full conversion support for TRANSACTION handle and TRANSACTION-MODE AUTOMATIC [CHAINED], and 'documentation driven' runtime. What is missing is testing in FWD and actual tx management.

From what I can see, for a tx to survive the appserver request, this needs to be marked in FWD 'one level above' the entry point block.

RUN ... TRANSACTION DISTINCT conversion and runtime (no-op at this time) already exists in FWD.

• full conversion support
• runtime is almost done, I need to do some more manual testing of implicit tx opening and transaction:set-commit/rollback.

Please take a close look at the TransactionManager - they are the main changes of managing the transactions at the root block (synthetic FWD block on index 0).

Eric: please help me with runtime testing - I don't think full runtime is required, just the 'cutdown' tests; you can go ahead with the conversion using 3754a/11292.

Code Review Task Branch 3754a Revision 11292

I've reviewed everything, it is very good.

The part I don't understand is how this is supposed to act when it is called while a full transaction is already active. Do I understand that it can be called at any time? It will force full transaction at the top level of the stack of blocks, but if there is already a full transaction further down, then I think the behavior of deeply nested processing will be incorrect. We assume that there is only one full transaction. As we let the exceptions bubble up the processing will be wrong because it will stop short at the inner full transaction. Am I misinterpreting how this is supposed to work?

Greg Shah wrote:

The part I don't understand is how this is supposed to act when it is called while a full transaction is already active.

Do you mean the TRANSACTION-MODE AUTOMATIC statement? If yes, then this statement can ever be called at the beginning of the program (you get a 4GL compile error if is not the first executable statement). And calling something from within the TRANS-INIT-PROCEDURE (which would start another tx) is allowed only if this is called remotely or if the current tx is started by TRANS-INIT-PROCEDURE.

The idea is: there is no way for TRANSACTION-MODE AUTOMATIC or TRANS-INIT-PROCEDURE invoked entries to automatically start a full tx, if there is one already active and not started by TRANS-INIT-PROCEDURE - 4GL has checks for this.

Otherwise, please clarify what part you mean by 'is supposed to act'.

there is no way for TRANSACTION-MODE AUTOMATIC or TRANS-INIT-PROCEDURE invoked entries to automatically start a full tx, if there is one already active and not started by TRANS-INIT-PROCEDURE - 4GL has checks for this

Yes, this was my concern.

Do we have sufficient checks to ensure this same limitation is forced?

Greg Shah wrote:

Do we have sufficient checks to ensure this same limitation is forced?

Now we do - see 3754a rev 11293.

11292 passed MAJIC runtime. If Eric's ETF cutdown testing passes, we can merge to trunk.

Code Review Task Branch 3754a Revision 11293

The changes are good.

If Eric's tests pass please merge to trunk.

Constantin Asofiei wrote:

Eric: please help me with runtime testing - I don't think full runtime is required, just the 'cutdown' tests; you can go ahead with the conversion using 3754a/11292.

ETF runtime testing passed (full search and dev tests). Do you want to review the converted code?

Eric Faulhaber wrote:

ETF runtime testing passed (full search and dev tests).

Great! I'll release it shortly.

Do you want to review the converted code?

No need, it only moved the IS-OPEN attribute to another FWD interface (and handle.unwrap API), compilation or runtime would have failed if something was wrong.