Mapping Transactions to Databases (Magic xpa 3.x)
To implement the transaction processing mechanism, Magic xpa utilizes the transaction processing facilities of the underlying databases. Since each database has its own transaction facilities, Magic xpa maps its internal transactions to those available in the various databases.
Note: In light of the above, transactions are not implemented in non-RDBMS data sources, such as Memory and XML. Trying to roll back a transaction when using a non-RDBMS data source will fail. In Memory data sources, each DML is considered committed, which may result in unpredictable behavior. This is especially the case when a transaction has both memory data and a real database, because the database records will be rolled back, but the memory records will not, causing data inconsistency.
According to the way ISAM databases implement transaction processing, Magic xpa maps its internal transaction in the following manner:
Read-transactions and Lock-transactions have no implementation in ISAM databases, therefore Magic xpa does not transfer them to the ISAM database gateways.
Write-transaction is mapped to the ISAM transaction, which logs the updates and is able to do rollback. Such a transaction can lock all or part of the table.
According to the way SQL databases implement transaction processing, Magic xpa maps its internal transaction in the following manner:
Read-transaction is mapped to an R/O (read only) transaction. This transaction takes snapshots of the database situation when the transaction is opened.
If the Access mode of all tables in a Lock or Write transaction is Read, the Lock or Write transaction is mapped to an R/O (read only) transaction. Otherwise, a Lock or Write transaction is mapped to an R/W (read/write) transaction. This transaction locks all the records referred within the transaction scope.
