Browse Prior Art Database

Runtime Transaction Management in a Transaction Service

IP.com Disclosure Number: IPCOM000123518D
Original Publication Date: 1998-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 202K

Publishing Venue

IBM

Related People

Hutchison, G: AUTHOR

Abstract

With traditional transaction servers, administration of transactions is greatly facilitated by the concept of a Transaction ID (e.g. CECI). This allows administrators and other users to observe transactional activity in the system grouped by transaction classes that have conceptual meaning to the users for the purposes of system monitoring, debugging and manual intervention in heuristic resync etc.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 36% of the total text.

Runtime Transaction Management in a Transaction Service

   With traditional transaction servers, administration of
transactions is greatly facilitated by the concept of a Transaction
ID (e.g. CECI).  This allows administrators and other users to
observe transactional activity in the system grouped by transaction
classes that have conceptual meaning to the users for the purposes of
system monitoring, debugging and manual intervention in heuristic
resync etc.

   However in the CORBA* defined Object Transaction Service
(OTS) as implemented in Component Broker (CB) and the Java**
Transaction Service (JTS) there is no analogous concept to a
transaction ID.  Transactions are all created as instances of the
same class 'Transaction' and are represented by a sequence of octets
(a byte string).  Transactions propagate between processes in a
similar manner, they can be compared for equality and such like but
there is no mechanism for grouping them into types or classes of
transaction that can be used to provide conceptual information for
the administrator.

   This means that systems like CB and JTS are much more
confusing to administer in cases where human understanding of
transactional activity is necessary (e.g. debugging or heuristic
hazard situations).

   For example the JTS has implemented an administration
interface which allows users to view and control the transactions in
a server.

   Actions that administrators will most commonly use this
interface for are observing transactional activity, resolving
deadlocks and manually forcing transaction completion in heuristic
situations.

   As is apparent, it is difficult for a human to be able to
deduce any useful information on what type of transaction he/she is
observing (or about to heuristically rollback for example).

   This is bad as transactions do not exit in isolation and
any heuristic action may well have to be reflected with similar
action in another server.  If the administrator was in a situation
requiring the transaction to be forced, it is impossible for him/her
to tell what other systems the transaction could have flowed to (or
to make any sensible guess) based on the transaction id.  His/her
best option currently is to search all possible servers looking for
an occurence of the same transaction id sequence.

   The approach described here enables a significant
improvement in usability of the transaction administration in a
system such as CB.

   In a running CORBA transaction system work (and
transactions) flow in and out of system processes in object packages
of type CORBA::request.  When a transaction is propogated into a
running server process it will be attached to a particular request.
This request will always be targeted at an object that is marked as
being 'transactional' by descending from (or implementing) the
CosTransactions::TransactionalObject interface.  However the target
object will also be of a particular type or 'Interface' in Corba
Terminology. ...