Browse Prior Art Database

Automatic failure diagnosis and resume for message processing in message driven bean scenarios Disclosure Number: IPCOM000016313D
Original Publication Date: 2002-Nov-14
Included in the Prior Art Database: 2003-Jun-21
Document File: 7 page(s) / 126K

Publishing Venue




This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 22% of the total text.

Page 1 of 7

  Automatic failure diagnosis and resume for message processing in message driven bean scenarios


    This section gives a short introduction into the main concepts and terminology used in this article.

Message Driven Beans

    TMMessage Driven Beans (MDB) were introduced with Sun's EJBTM 2.0 Specification, see [1]. MDBs are special Enterprise JavaBeans(EJB), i.e. pieces of code that implement certain interfaces so that they can run within a so called EJB Container runtime. In difference to the session beans and entity beans, the MDBs support an asynchronous programming model. A MDB object provides an onMessage method that is asynchronously invoked and executesupon receipt of a single client message. Although MDBs are short-lived stateless objects that do not represent database data directly, methods can access such data in a transaction-aware way. The container creates a new transaction before the message is sent to the onMessage method of MDBs with container-managed transactions.(In this article we don't use bean-managed transactions.). The transaction is committed after if onMessage returns properly. The MDB than can cause a transaction rollback by invoking a setRollbackOnly method on a certain context object. If a transaction is rolled back, the message stays in the input queue and will be posted to the MDB again.

    MDBs use concepts and interfaces that are described in the Java Messaging Service (JMS) specification see [2] . For the scenarios in this article, we need the following terms:

JMS Messages are objects that can be put into JMS destinations. Messages have a header and a body. The header has some standard header properties that provides some information (e.g. JMSXDeliveryCount that stores the number of times a message was redelivered to the MDB before.) to the message consumer by getter methods. Additionally it is possible to add custom properties to the message header. The message body contains the messages payload. The payload can be accessed by special getter methods depending on the message type (ObjectMessage, TextMessage, BytesMessage).

    JMS Queues are certain JMS destinations that support point-to-point messaging. For the scope of this article we assume that the JMS Queues represent MQSeries queues by a JMS interface (The minimal requirement is, that the messaging system supports the optional JMSXDeliveryCount message header property.). Later in this article discusses an approach where messages have to be moved from one queue to another. This step requires that the messages (including header properties and payload) are copied (There might be other solutions, but copying is easy to implement and works fine.). There are several reasons for that, two of them are:

Some header properties are set by the messaging system. Copying ensures reinitialization of those properties (e.g. JMSXDeliveryCount is set to 0 if the message copied into a queue). The Algorithm described below needs to set own properties. The JMS specif...