Transaction Processing (Magic xpa 3.x)
Transaction processing is a data processing technique used to preserve database integrity. It can be defined as the execution of a set of logically-related data modifications, which must be committed, completed, and written to disk, or aborted as a single unit.
Transactions can also be used to secure Read operations, as opposed to Read and Write operations. A Read transaction ensures that the data read within the transaction is not modified by other users.
The major benefit of transaction processing is protection from computer system crashes. If the computer crashes in the middle of online data entry or batch processing, the entire transaction is aborted. This prevents incomplete updates to the database, and maintains database consistency.
The Data Management and Magic xpa concept paper
Deferred transactions delay the implementation of Data Manipulation (DM) statements until the time that you must commit the changes made to records of a data view. Magic xpa stores each DM statement in a cache. When you are ready to commit the changes to the database, all changes are implemented concurrently. This keeps the transaction duration as short as possible.
When running a browser-based program, the user can open several browsers at once. Separate browsers can run separate tasks that have no transactional connection. Magic xpa supports different browsers by separating deferred transactions into logical branches. Each branch is its own transaction tree without any connection to other branches.
Magic xpa lets you open a nested transaction in a modeless task for a deferred transaction.
In a multi-user environment, deadlocks are a common cause of transaction failure. A deadlock situation occurs when two users are waiting for a resource that is locked by another user.
The various DBMSs behave differently when a deadlock occurs. Some DBMSs are able to detect the deadlock and issue a warning. In this case, Magic xpa rolls back the transaction and continues execution according to the error behavior strategy for the transaction.
Because some ISAM databases may hang in deadlock situations, Magic xpa provides a deadlock prevention mechanism for ISAM and SQL databases. The deadlock prevention mechanism exclusively locks all tables opened with Write access, in the same order as defined, for the period of the transaction. Temporary tables are not locked.
The Rollback function can be used to roll back a transaction to a specified nesting level, or to abort the transaction completely.
Unlike general purpose disk caches that employ generic algorithms for their caching, Magic xpa’s cache lets you fine-tune cache behavior according to your knowledge of the physical data and the nature of the application.
This cache does not call any file manager as other hardware or software caching methods might and therefore avoids the additional file manager overhead of traditional methods.
