Browse Prior Art Database

Selective Participation in Unit-of-Work Protocols

IP.com Disclosure Number: IPCOM000106397D
Original Publication Date: 1993-Nov-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 160K

Publishing Venue

IBM

Related People

Dievendorff, R: AUTHOR [+2]

Abstract

Disclosed is a method for performing application requests outside the UNIT OF WORK without regard to whether or not other requests have been made under a UNIT OF WORK. The UNIT OF WORK may be backed out without affecting completed operations that are outside the scope of that UNIT OF WORK. It relates to application requests to a message system, queuing system, recoverable file system, or database management system and allows an application program to specify that a given request to add or remove a message element is to be part of a UNIT OF WORK or is to be excluded from a UNIT OF WORK. Application designers are not restricted as to whether or not a request is recoverable, as recoverability is an attribute of the referenced resource rather than the request.

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

Selective Participation in Unit-of-Work Protocols

      Disclosed is a method for performing application requests
outside the UNIT OF WORK without regard to whether or not other
requests have been made under a UNIT OF WORK.  The UNIT OF WORK may
be backed out without affecting completed operations that are outside
the scope of that UNIT OF WORK.  It relates to application requests
to a message system, queuing system, recoverable file system, or
database management system and allows an application program to
specify that a given request to add or remove a message element is to
be part of a UNIT OF WORK or is to be excluded from a UNIT OF WORK.
Application designers are not restricted as to whether or not a
request is recoverable, as recoverability is an attribute of the
referenced resource rather than the request.

      The problem relates to a transaction-orientated message queuing
system whose primary operations are PUT MESSAGE and GET MESSAGE.  In
most applications it is appropriate that messages be treated as any
other recoverable resource.  Changes to messages (insert and delete
operations) are made permanent by a COMMIT operation or are removed
completely by a BACKOUT operation.  Changes to these resources are
coordinated with changes to other resources, such as database
records, made by the transaction.  If the decision to make permanent
or erase the messages inserted by a transaction does not occur until
COMMIT, it follows that messages may not be made available to their
destinations until the transaction reaches a COMMIT point.  Some
applications designs are inhibited by this constraint and may be
written in a more straightforward manner by permitting some PUT
MESSAGE and GET MESSAGE operations to be performed outside of the
scope of a UNIT OF WORK.

      The disclosed solution is to provide alternative ways of
invoking the GET MESSAGE and PUT MESSAGE so that the application
program may determine whether or not the GET MESSAGE or PUT MESSAGE
should be part of or should be excluded from the current UNIT OF
WORK.  Requests outside the UNIT OF WORK scope are treated as if they
were in a nested UNIT OF WORK of their own.  Once such an operation
completes it may not be undone even though other requests made within
the UNIT OF WORK scope are undone by transaction BACKOUT.  An example
of this style of application is:

1.  GET MESSAGE request (within UNIT OF WORK scope)
2.  PUT MESSAGE request to a server (outside UNIT OF WORK scope)

3.  WAIT for response message from server
4.  GET MESSAGE response from server (outside UNIT OF WORK scope)
5.  Update database (within UNIT OF WORK scope)
6.  PUT MESSAGE reply to originator (within UNIT OF WORK scope)
7.  COMMIT all updates made within the UNIT OF WORK

Note that the PUT MESSAGE in step 2 cannot be deferred until the
COMMIT point as the transaction would wait forever for the server's
response message to appear.

      The implementation permits messages to be d...