Browse Prior Art Database

Optimization of transaction contexts in a nested object model

IP.com Disclosure Number: IPCOM000014568D
Original Publication Date: 2001-Aug-17
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 40K

Publishing Venue

IBM

Abstract

Disclosed is a mechanism for optimizing the management of transaction contexts in a nested object model. A business object model is typically implemented using a hierarchy of objects invoking other objects, such as the component broker managed object framework, a set of enterprise beans or a set of business process beans. There may be several layers involved in different aspects of transaction management. At the lowest level of management, transactional resources examine contexts associated with a thread of execution to determine on which transaction the thread is performing work. The transaction manager therefore needs to ensure that the correct transaction context is established on the thread of execution during execution of work for a transactional resource. Many transaction managers can achieve this by placing the transaction context on the thread when the transaction begins and not permitting other work to use that thread until the transaction is completed. In many transaction server systems, it is desirable to permit many simultaneous clients to access the transaction server. If the transaction manager wishes to support many more simultaneous transactions than available threads, it will need to manage the transaction contexts and, in particular, add and remove the transaction contexts as work for those transactions is processed by the server. If the work is divided up into a hierarchy of objects, the server can use the division between the objects as a mechanism for either distributing the work across several servers, or to permit many transactions to share a limited number of threads by manipulating the transaction contexts as required. In such a system it is possible to support 'open nested transactions'. An open nested transaction is one which is wholly contained inside another transaction, but does not contribute to the success or failure of the enclosing transaction. This manipulation of the transaction context can prove to be an expensive operation. Transaction 1

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

Page 1 of 2

Optimization of transaction contexts in a nested object model

Disclosed is a mechanism for optimizing the management of transaction contexts in a nested object model.

     A business object model is typically implemented using a hierarchy of objects invoking other objects, such as the component broker managed object framework, a set of enterprise beans or a set of business process beans. There may be several layers involved in different aspects of transaction management.

     At the lowest level of management, transactional resources examine contexts associated with a thread of execution to determine on which transaction the thread is performing work. The transaction manager therefore needs to ensure that the correct transaction context is established on the thread of execution during execution of work for a transactional resource. Many transaction managers can achieve this by placing the transaction context on the thread when the transaction begins and not permitting other work to use that thread until the transaction is completed. In many transaction server systems, it is desirable to permit many simultaneous clients to access the transaction server. If the transaction manager wishes to support many more simultaneous transactions than available threads, it will need to manage the transaction contexts and, in particular, add and remove the transaction contexts as work for those transactions is processed by the server. If the work is divided up into a hierarchy of objects, the server can use the division between the objects as a mechanism for either distributing the work across several servers, or to permit many transactions to share a limited number of threads by manipulating the transaction contexts as required. In such a system it is possible to support 'open nested transactions'. An open nested transaction is one which is wholly contained inside another transaction, but does not contribute to the success or failure of the enclosing transaction. This manipulation of the transaction context can prove to be an expensive operation.

Transaction 1

Client Program C

Transaction 2

Object 2

Object 2.1

Leaf Object 2.1.1

Object 1

Object 1.1

Leaf Object 1.1

Leaf Object 1.1.1

The diagram shows a typical hierarchy of objects....