Transactions¶
Transactions are normally handled by the client in IFS Cloud. The client decides whether a transaction should be committed or rolled back. Please remember that a number of things can be considered as a client, e.g. IEE client, web client, background jobs, reports and so on. All of these different clients must take the decision of how to handle the various transactions.
IEE client¶
The client framework includes the transaction handling in the call to the server and the server code does not need to bother about the transaction.
The example is a typical call from the client to the server. If anything goes wrong a rollback
is done; otherwise the client will issue another call to commit the transaction. &AO is a replacement variable for Appowner.
Background jobs¶
Server code that is supposed to be run as a background job must take care of the transaction itself since the background job itself is acting as the client. Thus the server code has to consider where to commit and how to handle an error. Server code that handles a transaction must be annotated by a transactional annotation. If the server code has no transactional annotation, then the transaction is not yet regarded as secure, even if the transaction works as expected.
In this example we can see that we have added a commit
in the procedure to handle the transaction. We can also see that we have annotated the commit
statement.
Autonomous transactions¶
Autonomous transactions are a way to start a new transaction within the main transaction. An autonomous transaction must always end with a commit, otherwise it will not compile. The autonomous transaction is used in server code and is usually used for logging purposes. One example where autonomous transactions can be used is if the server code wants to log something that has happened even if the main transaction rollbacks. Autonomous transactions should normally only occur in the server framework.
This example shows a typical procedure that writes some logging information into a table in its own autonomous transaction. If this method is called from another method it will always put a row into the log if it is executed even if the calling method fails.
DDL¶
Remember that all DDL (Data Definition Language) statements run in the server code, such as deploying a package or creating a table, makes a commit before the DDL statement is run. Therefore it is important that DDL statements only occur in the framework code.
Transactional annotations¶
All server code that holds a transactional command must be annotated. The annotation is done by entering:
@ApproveTransactionStatement(2013-10-30,haarse)
The meaning of this annotation is to approve the transactional code by entering your id and date.