I am researching transaction processing and while I have read about COMMIT, LOGOUT and ROLLBACK, I don’t seem to be able to find any discussions/writing about how to implement it. Is there a template enabler, do you just put statements in EMBEDS, or what? I would like to read about it - more than what the Language Reference has in it. Like an article or something. Any ideas?
The template already has transactions around RI code, if you have that template option turned on.
So with regard to where you use them, it’ll be in embed code around code where you are doing multiple writes.
They come at a cost so typically are used when the group of writes are “all or nothing”. They are typically not used for single write commands.
Is there anything else you specifically want yo know?
thanks Bruce. I looked through the templates in my app and cannot see where transactions are enable/disabled.
regarding usage in EMBEDS, does LOGOUT mess things up because the templates themselves are opening/closing data files and LOGOUT/Commit are doing the same.
Mark
Logout and Commit don’t open tables.
They’re used in addition to all the regular file driver commands, not in place of. the file has to be OPEN before you can do a LOGOUT on it.
For the global template setting see;
Global Properties, Actions, File Control, “Enclose RI code in transaction frame”.
Cheers
Bruce
In general you will use LOGOUT in Embeds.
As Bruce points out the system does use LOGOUT, particularly in the relation manager to ensure the relational integrity constraints are either done or not, and there are template prompts to assist in that. There’s also a template extension or 2 to deal with it.
But in general this in something you want control over and so will embed explicitly. (eg in a process procedure to do all or rollback on error)
Another small caveat -
for any tables using the In-Memory driver, you should set “Use RI transaction frame” to NO in the app’s global properties. (See page 13 of the InMemoryDriverRef.pdf)
Another consideration, move to an SQL backend if possible and simplify the transaction details that must be learned.
There are two places in the regular templates/classes where logout/rollback/commit happens. The first is in the relationmanager classes. You can see them in action in the ABFILE.CLW file in libsrc. Simplifying, what the Update class, for example, does is:
logout
try to update the main file
if it fails, then rollback
If it doesn’t fail, then carry out cascading updates on child files
If that works then commit, otherwise rollback.
Those cascading updates on child files are things that you have declared in your dictionary in the “relations” section, so really you are talking about cascading changes to linking fields, which in general you don’t want to do (I hope). So mostly all that happens is that a logout/commit is put around your single update.
The second place that they occur is when you add a Transaction manager to the procedure (using the extensions tab on a form). This template suspends the regular relationmanager logout/commit (it sets the UseLogout property to false), gives you a logout at the start of the transaction, gives you a place (ThisTransaction.Process) to put any other changes that you want in your transaction, and commits at the end if everything has worked out, otherwise rolls back.
So, for example, if you are entering a transaction in a general ledger, and your main update is to the GL file, but you also need to decrement the bank_account and liabilities table by matching amounts, you would put those updates in ThisTransaction.Process.
I’ll also mention low level activities. Most (SQL) access from clarion is handled by the ODBC driver, or the somewhat modified MSSQL driver. The default for an ODBC connection is to commit every transaction automatically. The LOGOUT command suspends autocommit and by default chnages the isolation level to ReadCommitted. When you commit the transaction, as well as sending a COMMIT to the server you are back to auto-committing. That’s basically what the driver does to “transalate” the LOGOUT and COMMIT statements.
Just to add a couple of things:
The default ThisTransaction.Process method does absolutely nothing. So if you add the Transaction Manager template, you have to manually add the relationmanager call(s) for your primary file in the Process method just to get back to where you were before you added the template.
For a long time the instructions for the template said to add you code to ThisTransaction.Run, which is wrong. I reported this at some point, but if you are using an older version it will probably still tell you this.