Communicator e3000 MPE/iX Release 6.5 (Non-Platform Software Release C.65.00 (30216-90291)

126 Chapter5
Internet and Interoperability
Large Transactions for IMAGE Users
Large Transactions for IMAGE Users
By B T Vikram Kumar, B S Jyoti, Shobha Pradeep
Commercial Systems Division
Background
Of late many of the users of TurboIMAGE and IMAGE/SQL have the requirement of
transaction sizes larger than is currently possible today (4 MB). This is true, especially for
users who run applications involving bulk puts/ deletes /updates. The situation becomes
more difficult with the limitation of the size of the Transaction Manager (XM) userlog, if
the transactions are on the same volume set. This integrated solution involving
TurboIMAGE/iX, XM, IMAGE/SQL and ALLBASE/SQL addresses these problems. The
following sections discuss these issues, and various options available to the users to
overcome these issues, as a result of this solution.
Current Limitations
Version C.03.00 of TurboImage introduced the concept of dynamic transaction, meaning
the application can rollback a transaction at runtime. Later when the Transaction
Manager started handling the dynamic transactions, some customers used to see the
stalled transaction message due to the limit on the size of the transaction.
Transaction Size Dynamic transactions are the ones which are bracketed by DBXBEGIN
and DBXEND or DBXUNDO, which may span a single database or multiple
databases. In the case of multiple database transactions the total number
of databases which can take part in a transaction is restricted to 15. A
dynamic transaction can be rolled back using DBXUNDO or automatically
when the application aborts within a transaction. When an application
does a bulk insert, delete or update, there is a chance that it hits the
current limit of 4 MB on transaction size. Until recently, the process used
to abort under such situation, after displaying an error message that the
transaction size has exceeded. An intermediate solution has been provided
(patch MPEKX35) to rollback the transaction before process abort, so as to
leave the database in a consistent state, and user could re-run the
application after manually pruning the application. However, this was not
a comfortable alternative, and users have been requesting that there be an
increase in the transaction size.
User Log Size The user log related limit arises due to the fact that XM in MPE is
log-based. That is all the transactions, mainly the ones which involve
manipulation to the database, are logged on to a circular log file. When
there are many applications writing into the XM log file, it could also get
filled up easily, again resulting in process abort. The userlog (all references
to userlog in this article refers to XM userlog) comes into the picture here
because all the changes to IMAGE databases on a specific volume set are
written to the same userlog. If only the transaction size limit is increased,
because of the increased number of open transactions, the 64 MB limit is
easily attained.