Browse Prior Art Database

Transaction Tags: How the Programmer Can Help the Recovery Operator

IP.com Disclosure Number: IPCOM000119954D
Original Publication Date: 1991-Mar-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 3 page(s) / 100K

Publishing Venue

IBM

Related People

Pruul, EA: AUTHOR [+2]

Abstract

Transaction Tag is a way the application program can save instructions to the recovery operator as part of a distributed system's transaction recovery data. When doing a two-phase commit protocol, if committing of the application's resource changes could not either fully complete in all resources or be totally backed-out, the operator could easily determine what action to take by displaying the Transaction Tag field of the transaction's recovery data. (Image Omitted)

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

Transaction Tags: How the Programmer Can Help the Recovery Operator

      Transaction Tag is a way the application program can save
instructions to the recovery operator as part of a distributed
system's transaction recovery data.  When doing a two-phase commit
protocol, if committing of the application's resource changes could
not either fully complete in all resources or be totally backed-out,
the operator could easily determine what action to take by displaying
the Transaction Tag field of the transaction's recovery data.

                            (Image Omitted)

      If the recovery operators for each of the systems and resources
involved in a distributed transaction are forced into a situation
where they must recover (commit or back out) an incomplete
transaction, how do they know what to do?

      The operator is in a tough spot.  End-users may call
complaining that their data bases are locked and they cannot do
anything.  If the operator forces an incomplete transaction to commit
while another operator or the system itself makes a backout decision
for the same distributed transaction, the corporation's data bases
would be inconsistent with each other.  The operator is in a dilemma
and does not have the skill-level required to make this difficult
decision.

      Setting a default action that the system should choose if a
transaction cannot be resynchronized automatically by the system, in
a reasonable time, does not adequately address the problem.  The
content of the data being changed could dictate the actions to be
taken.  The calendar data for an executive may be considered more
critical to a business than that of a engineer, who could probably
recover without assistance incidentally.  When applications are
actually comprised of several transactions, the proper action could
be different for each transaction.  The problem is worse than simply
pre-determining which direction each transaction should go.  In
practice, coordination of all the recovery operators involved in the
distributed transaction is necessary.  Resource Manager operators, in
particular, must coordinate their actions.

     ...