Concepts - Deferred Transactions (Magic xpa 3.x)

As we saw in the previous section in the case of our happy couple, Fred and Wilma, it is important to make the transaction as short as possible. By making the transaction short, the lock resulting from a transaction is also short and therefore the other users will wait less for the data. This obviously increases concurrency.

The idea behind a deferred transaction is that all the changes to the database are kept in the cache memory (client memory or server memory). What do we mean by changes to the database? These are the Data Manipulation statements such as INSERT, UPDATE and DELETE.

When this transaction has completed, all the database changes will be written to the database in one short transaction, which we will refer to as the physical transaction. Now, the actual transaction is short. By using this type of transaction, the concurrency of the application has been greatly increased. Other benefits of deferred transactions are reduced server-side activity, reduced communications between the application and the database, and improved performance.

Let us take our happy couple’s predicament and see how this will help them out. Dear Fred is standing in front of the clerk, waiting patiently for the clerk to finish the conversation. The clerk is using data that has been implemented as a deferred transaction. Now, Wilma comes along and wants to transfer the money. Lo and behold, there is no problem. She performs the transaction, as a deferred transaction as well. The database is updated; there is now money in the Checking account and she can withdraw the money that she wanted to withdraw in the first place. She can take up matters with Fred later.

What we can see here is a major advantage of using a deferred transaction; the actual physical transaction is much shorter and, by default, the data locking is also shorter. The clerk sitting on the phone no longer influences Wilma.