Browse Prior Art Database

Ensuring Trigger-First Messages Written if Transactions Abort

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

Publishing Venue

IBM

Related People

Dievendorff, R: AUTHOR [+3]

Abstract

Disclosed is a method of providing a recoverable trigger function within a queuing system that does not have a queue-level exclusive lock. A recoverable trigger function is when a triggering event is guaranteed to occur if the initiating transaction commits, or guaranteed not to occur if the initiating transaction rolls back.

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

Ensuring Trigger-First Messages Written if Transactions Abort

      Disclosed is a method of providing a recoverable trigger
function within a queuing system that does not have a queue-level
exclusive lock.   A recoverable trigger function is when a triggering
event is guaranteed to occur if the initiating transaction commits,
or guaranteed not to occur if the initiating transaction rolls back.

      In the context of a Message Queuing System, there was a
requirement for the Message Queuing system to generate a Trigger
Message - by writing it to a queue identified as the Initiation Queue
- when a Queue identified as having the Trigger-First attribute
became non-empty.  Additionally there was a requirement that such a
Trigger Message was never 'missed', i.e., no matter what the
circumstances, if the Triggering event occurred, the Message Queuing
system must ensure that the Trigger message was generated.   The
particular problem addressed by this disclosure is that the Queue
Depth, by which the Triggering process is driven, contains both
Committed and Uncommitted message counts leading to the following
potential problem.

      A transaction puts a message to a queue defined as a
Trigger-First queue that is currently empty; the triggering process
sees the queue depth going from ZERO to ONE, generates a Trigger
Message, and puts it - within the Unit of Work - to the Initiation

Queue.  Another transaction puts a message - within a different Unit
of Work - to the same Trigger-First Queue; this time the triggering
process sees the queue depth going from ONE to TWO, so does NOT
generate a Trigger Message and this second transaction COMMITS, thus
making the message that it wrote to the Trigger-First Queue visible.
Now the first transaction ROLLs BACK - causing both the Message on
the Trigger-First Queue and the Trigger Message written to the
Initiation Queue to disappear.

      Now there is a situation where there is a message on the
Trigger-First Queue (from the second transaction), a Queue Depth of
ONE, but NO Trigger Message  has been generated, thus violating the
Trigger-First rules.   The solution is to ensure that the Trigger
Message that was generated by the first transaction in the problem
scenario is wri...