Browse Prior Art Database

Container-managed Compensation for Enterprise Java Beans that use Container-managed Persistence

IP.com Disclosure Number: IPCOM000028529D
Original Publication Date: 2004-May-19
Included in the Prior Art Database: 2004-May-19
Document File: 4 page(s) / 59K

Publishing Venue

IBM

Abstract

When an application consists of multiple transactions, changes that are committed in one part of the application cannot be automatically undone if the application fails at a later point. For example, when Enterprise Java Beans (EJBs) that use Container-managed persistence (CMP) are accessed with TxRequiresNew semantics, CMP data updates are made persistent at method end (when the transaction commits). If failures subsequently occur in the application then there is presently no mechanism which will automatically undo those commited data updates. The application has to do what it can to make the application data consistent which is generally a complex and onerous task. This invention provides a mechanism in the middleware which hosts the application to automatically perform such compensation and return the application data to a consistent state.

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 34% of the total text.

Page 1 of 4

Container-managed Compensation for Enterprise Java Beans that use Container-managed Persistence

A method is disclosed that enables enterprise middleware, such as a Java* 2 platform, enterprise edition (J2EE) application server, to provide consistency of application data in the event of failure of some part of an application that consists of multiple units of work.

    When a CMP Enterprise JavaBean* (EJB) is first loaded into the application server, a 'before image' of its data is taken; if the transaction under which the method is invoked (transaction 1) subsequently commits , both the 'before' and 'after' images will be persisted, and this data will be associated with the transaction of the caller of the CMP EJB (transaction 0). If that transaction (0) fails, the EJB data can be reloaded, and if it still matches the saved 'after' image, the saved data will be used to 'compensate' (logically undo) the committed work by overwriting the changed data with the 'before' image. If that transaction (0) succeeds, however, the compensating data for both transactions 1 and 0 will be associated with the transaction of the caller of transaction (0) and so on. This mechanism of 'promoting' compensation data up through the hierarchy of transactions in the application builds a structure in which all the CMP data can remain committed or all be rolledback/compensated and so remain consistent for the whole application.

    There are two basic mechanisms required to make this method work: a scoping structure that reflects the relationships between the separate transactions in the application and provides an association between compensating data and an appropriate scope, and the logic that collects the data that would be needed to perform compensation (the 'before' and 'after' images of the CMP bean) and registers this data with the current compensation scope.

    Compensation scoping could, for example, be based on the J2EE Activity service which provides thread association, propagation of context over RMI/IIOP and distributed signalling at completion. Such compensation scopes would be begun by the EJBContainer as directed by deployment descriptors on the application methods. In this way the application developer can define which part of the application controls whether or not compensation is driven for work performed within the scope of the application. A new compensation scope would enlist as a transactional resource with the current transaction, and in doing so would be guaranteed to be reliably informed of the transaction outcome. When a different EJB method is invoked from within the scope of the first transaction/compensation scope, the first transaction scope is suspended and a new transaction begun; the first compensation scope, however, is not suspended but remains active on the thread and a new compensation scope (enlisted as a resource with the new transaction) is begun as a nested child of the first compensation scope. This parent-child relationshi...