Este contenido no está disponible en el idioma seleccionado.

9.2. JBoss Transaction Service


In keeping with the object-oriented view, the mechanisms needed to construct reliable distributed applications are presented to programmers in an object-oriented manner. Some mechanisms, such as concurrency control and state management, need to be inherited. Others, such as object storage and transactions, are implemented as JBoss Transaction Service objects that are created and manipulated like any other object.

Note

When using persistence and concurrency control facilities, it is assumed that the Transactional Objects for Java (TXOJ) classes are being used. Other mechanisms are not discussed here.
JBoss Transaction Service uses object-oriented techniques to present programmers with a toolkit of Java classes which application classes can inherit to obtain desired properties, such as persistence and concurrency control. These classes form a hierarchy, part of which is shown below and which will be described later in this document.

Figure 9.1. JBoss Transaction Service Class Hierarchy

The programmer is only responsible for specifying the scopes of transactions and setting appropriate locks within objects. JBoss Transaction Service and Transactional Objects for Java (TXOJ) ensure registration and function with the appropriate transactions, as well as crash recovery in the case of failure.

9.2.1. Saving Object States

JBoss Transaction Service remembers the state of an object. It needs this information for recovery , in which the state represents some past state of the object, and persistence, in which the state represents the final state of an object at application termination. All of these requirements are implemented using the same mechanism: the InputObjectState class and the OutputObjectState class. The classes maintain an internal array into which instances of the standard types can be contiguously packed and unpacked using pack and unpack operations. This buffer is automatically resized as required. The instances are all stored in the buffer in a standard machine-independent form called network byte order. Any other architecture-independent format, such as XDR or ASN.1), can be implemented by replacing the classes with the ones corresponding to the pack and unpack function in the required format.
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat