Sunday, April 22, 2007

[completeJava] New file uploaded to completeJava


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the completeJava
group.

File : /Java/http-email-commons.jar
Uploaded by : b.thirupathi <thirupathi_reddy_82@yahoo.com>
Description : Apache commons for HTTP-Client, Email

You can access this file at the URL:
http://groups.yahoo.com/group/completeJava/files/Java/http-email-commons.jar

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

b.thirupathi <thirupathi_reddy_82@yahoo.com>


__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

New web site?

Drive traffic now.

Get your business

on Yahoo! search.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Posted by at No comments:

Saturday, April 21, 2007

[completeJava] Checkout these Ajax Components

Check AJAX Components @

http://www.nitobi.com/products/completeui/demos/explorer/index.html

Complete UI Featured Products

Save Yourself Time, Save Your Boss's Money and Look Like a Genius! Download Complete UI: Seven Killer Ajax Components:

 

__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Ads on Yahoo!

Learn more now.

Reach customers

searching for you.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Posted by at No comments:

Saturday, April 7, 2007

[completeJava] Nested Transactions

A nested transaction is used to provide a transactional guarantee for a subset of operations performed within the scope of a larger transaction. Doing this allows you to commit and abort the subset of operations independently of the larger transaction.

The rules to the usage of a nested transaction are as follows:

  • While the nested (child) transaction is active, the parent transaction may not perform any operations other than to commit or abort, or to create more child transactions.

  • Committing a nested transaction has no effect on the state of the parent transaction. The parent transaction is still uncommitted. However, the parent transaction can now see any modifications made by the child transaction. Those modifications, of course, are still hidden to all other transactions until the parent also commits.

  • Likewise, aborting the nested transaction has no effect on the state of the parent transaction. The only result of the abort is that neither the parent nor any other transactions will see any of the database modifications performed under the protection of the nested transaction.

  • If the parent transaction commits or aborts while it has active children, the child transactions are resolved in the same way as the parent. That is, if the parent aborts, then the child transactions abort as well. If the parent commits, then whatever modifications have been performed by the child transactions are also committed.

  • The locks held by a nested transaction are not released when that transaction commits. Rather, they are now held by the parent transaction until such a time as that parent commits.

  • Any database modifications performed by the nested transaction are not visible outside of the larger encompassing transaction until such a time as that parent transaction is committed.

  • The depth of the nesting that you can achieve with nested transaction is limited only by memory.

A JTS transaction manager must support flat transactions; support of nested transactions is optional. If a client begins a transaction, and within that transaction begins another transaction, the latter operation will throw a NotSupportedException if the JTS implementation does not support nested transactions.

Keep in mind that even if the JTS implementation supports nested transactions, this transaction manager-level support does not guarantee support for nested transactions in an application. For example, the EJB 1.1 specification does not support nested transactions.



__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

New web site?

Drive traffic now.

Get your business

on Yahoo! search.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Posted by at No comments:

[completeJava] Two Phase Commit

A commit operation is, by definition, an all-or-nothing affair. If a series of operations bound as a transaction cannot be completed, the rollback must restore the system (or cooperating systems) to the pre-transaction state.

In order to ensure that a transaction can be rolled back, a software system typically logs each operation, including the commit operation itself. A transaction/recovery manager uses the log records to undo (and possibly redo) a partially completed transaction.

When a transaction involves multiple distributed resources, for example, a database server on each of two different network hosts, the commit process is somewhat complex because the transaction includes operations that span two distinct software systems, each with its own resource manager, log records, and so on. (In this case, the distributed resources are the database servers.)

Two-phase commit is a transaction protocol designed for the complications that arise with distributed resource managers. With a two-phase commit protocol, the distributed transaction manager employs a coordinator to manage the individual resource managers.

The commit process proceeds as follows:

  • Phase 1
    • Each participating resource manager coordinates local operations and forces all log records out:
    • If successful, respond "OK"
    • If unsuccessful, either allow a time-out or respond "OOPS"
  • Phase 2
    • If all participants respond "OK":
      • Coordinator instructs participating resource managers to "COMMIT"
      • Participants complete operation writing the log record for the commit
    • Otherwise:
      • Coordinator instructs participating resource managers to "ROLLBACK"
      • Participants complete their respective local undos

In order for the scheme to work reliably, both the coordinator and the participating resource managers independently must be able to guarantee proper completion, including any necessary restart/redo operations. The algorithms for guaranteeing success by handling failures at any stage are provided in advanced database texts.

__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Ads on Yahoo!

Learn more now.

Reach customers

searching for you.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Posted by at No comments:

[completeJava] Re: Java Transaction Service

Chapter 14: Transaction Services with JTA and JTS

In this chapter, we describe more than the mere application of transactions to databases. We explore those services used to manage transactions in a distributed enterprise system. Distributed objects need to coordinate and define boundaries for access to shared resources. Transaction services provide such support. This chapter expands on the transaction problem and generic transaction service architecture, the CORBA Object Transaction Service (OTS), the Java Transaction API (JTA), and the Java Transaction Service (JTS). As you'll see, the JTS is a Java mapping of the OTS. Finally, we also touch on the latest developments in industry and with Java as it regards transactional Web services.

The JTA and OTS/JTS are all core underlying components that can be utilized by J2EE-based servers. The J2EE specification, in fact, requires that certain APIs defined by the JTA be incorporated into J2EE-compliant servers. Although the J2EE's declarative model for using transactions simplifies application programming, much of the literature and declarative programming conventions describing transaction usage with the J2EE is described in the context of JTA and OTS/JTS constructs and concepts. A basic understanding of the underlying transactions framework will help you make better decisions as an enterprise developer to determine what the best model for declaring transactions is for your components, as well as perhaps being useful for creating standalone distributed enterprise applications.

For good stuff on JTA and JTS :

http://www.developer.com/java/ent/article.php/2224921

__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Ads on Yahoo!

Learn more now.

Reach customers

searching for you.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Posted by at No comments:

[completeJava] Re: Java Transaction Service

Transaction Service

This section provides information that programmers need to write transactional applications for the WebLogic Server system.

This section discusses the following topics:

 

About the Transaction Service

WebLogic Server provides a Transaction Service that supports transactions in EJB and RMI applications. In the WebLogic Server EJB container, the Transaction Service provides an implementation of the transaction services described in the Enterprise JavaBeans Specification 2.0, published by Sun Microsystems, Inc.

For EJB and RMI applications, WebLogic Server also provides the javax.transaction and javax.transaction.xa packages, from Sun Microsystems, Inc., which implements the Java Transaction API (JTA) for Java applications. For more information about JTA, see the Java Transaction API (JTA) Specification 1.0.1a, published by Sun Microsystems, Inc. For more information about the UserTransaction object that applications use to demarcate transaction boundaries, see the WebLogic Server Javadoc.

 

Capabilities and Limitations

This section includes the following sections:

These sections describe the capabilities and limitations of the Transaction Service that supports EJB and RMI applications:

Lightweight Clients with Delegated Commit

A lightweight client runs on a single-user, unmanaged desktop system that has irregular availability. Owners may turn their desktop systems off when they are not in use. These single-user, unmanaged desktop systems should not be required to perform network functions such as transaction coordination. In particular, unmanaged systems should not be responsible for ensuring atomicity, consistency, isolation, and durability (ACID) properties across failures for transactions involving server resources. WebLogic Server remote clients are lightweight clients.

The Transaction Service allows lightweight clients to do a delegated commit, which means that the Transaction Service allows lightweight clients to begin and terminate transactions while the responsibility for transaction coordination is delegated to a transaction manager running on a server machine. Client applications do not require a local transaction server. The remote implementation of UserTransaction that EJB or RMI clients use delegates the actual responsibility of transaction coordination to the transaction manager on the server.

Client-initiated Transactions

A client, such as an applet, can obtain a reference to the UserTransaction and TransactionManager objects using JNDI. A client can begin a transaction using either object reference. To get the Transaction object for the current thread, the client program must invoke the ((TransactionManager)tm).getTransaction() method.

Transaction Integrity

Checked transaction behavior provides transaction integrity by guaranteeing that a commit will not succeed unless all transactional objects involved in the transaction have completed the processing of their transactional requests. The Transaction Service provides checked transaction behavior that is equivalent to that provided by the request/response interprocess communication models defined by The Open Group.

Transaction Termination

WebLogic Server allows transactions to be terminated only by the client that created the transaction.

Note: The client may be a server object that requests the services of another object.

Flat Transactions

WebLogic Server implements the flat transaction model. Nested transactions are not supported.

Relationship of the Transaction Service to Transaction Processing

The Transaction Service relates to various transaction processing servers, interfaces, protocols, and standards in the following ways:

  • Support for The Open Group XA interface.The Open Group Resource Managers are resource managers that can be involved in a distributed transaction by allowing their two-phase commit protocol to be controlled via The Open Group XA interface. WebLogic Server supports interaction with The Open Group Resource Managers.
  • Support for the OSI TP protocol. Open Systems Interconnect Transaction Processing (OSI TP) is the transactional protocol defined by the International Organization for Standardization (ISO). WebLogic Server does not support interactions with OSI TP transactions.
  • Support for the LU 6.2 protocol. Systems Network Architecture (SNA) LU 6.2 is a transactional protocol defined by IBM. WebLogic Server does not support interactions with LU 6.2 transactions.
  • Support for the ODMG standard. ODMG-93 is a standard defined by the Object Database Management Group (ODMG) that describes a portable interface to access Object Database Management Systems. WebLogic Server does not support interactions with ODMG transactions.

Multithreaded Transaction Client Support

WebLogic Server supports multithreaded transactional clients. Clients can make transaction requests concurrently in multiple threads.

General Constraints

The following constraints apply to the Transaction Service:

  • In WebLogic Server, a client or a server object cannot invoke methods on an object that is infected with (or participating in) another transaction. The method invocation issued by the client or the server will return an exception.
  • In WebLogic Server, clients using third-party implementations of the Java Transaction API (for Java applications) are not supported.
  • The transaction log buffer is limited to 250 KB. If your application includes very large transactions that require transaction log writes that exceed this value, WebLogic Server will throw an exception. In that case, you must reconfigure your application to work around the buffer size.

 

Transaction Scope

The scope of a transaction refers to the environment in which the transaction is performed. WebLogic Server supports transactions on standalone servers, between non-clustered servers, between clustered servers within a domain, and between domains. To enable inter-domain transaction support, you must configure a common credential for all participating domains. See Configuring Domains for Inter-Domain Transactions in the Administration Console Online Help .

 

Transaction Service in EJB Applications

The WebLogic Server EJB container provides a Transaction Service that supports the two types of transactions in WebLogic Server EJB applications:

  • Container-managed transactions. In container-managed transactions, the WebLogic Server EJB container manages the transaction demarcation. Transaction attributes in the EJB deployment descriptor determine how the WebLogic Server EJB container handles transactions with each method invocation.
  • Bean-managed transactions. In bean-managed transactions, the EJB manages the transaction demarcation. The EJB makes explicit method invocations on the UserTransaction object to begin, commit, and roll back transactions. For more information about UserTransaction methods, see the online Javadoc.

For an introduction to transaction management in EJB applications, see Transactions in WebLogic Server EJB Applications, and Transactions Sample EJB Code in the Introducing Transactions section.

 

Transaction Service in RMI Applications

WebLogic Server provides a Transaction Service that supports transactions in WebLogic Server RMI applications. In RMI applications, the client or server application makes explicit method invocations on the UserTransaction object to begin, commit, and roll back transactions.

For more information about UserTransaction methods, see the online javadoc. For an introduction to transaction management in RMI applications, see Transactions in WebLogic Server RMI Applications, and Transactions Sample RMI Code in the Introducing Transactions section.

 

Transaction Service Interoperating with OTS

WebLogic Server provides a Transaction Service that supports interoperation with the Object Transaction Service (OTS). See the Java Transaction Service (JTS) Specification. For this release, WebLogic Server interoperates with OTS in the following scenarios:

Server-Server 2PC

In this situation, a server-to-server 2PC transactin is completed using interposition. The originating server creates an xid and propagates the transaction to the target server. The target server registers itself as a resource with the originating server. The originating server drives the completion of the transaction. (no last resource optimization).

Client demarcated transactions

The client starts a transaction on the server via the OTS client APIs. The client then retrieves the xid from this transaction and then propagates this per-request until the transaction is commited. Although the client initiates the transaction, all the commit processing is done on the server.

__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Search Ads

Get new customers.

List your web site

in Yahoo! Search.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Posted by at No comments:

[completeJava] Java Transaction Service

Java Transaction Service

Subbu Allamaraju

Introduction

Transaction management is one of the most crucial requirements for enterprise application development. Given the complexity of today's business requirements, transaction processing occupies one of the most complex segments of enterprise level distributed applications to build, deploy and maintain.

By definition, a transaction is a unit of work done by multiple distributed components on shared data, with the following properties:

  • ATOMICITY: A transaction should be done or undone completely and unambiguously. In the event of a failure of any operation, effects of all operations that make up the transaction should be undone, and data should be rolled back to its previous state.
  • CONSISTENCY: A transaction should preserve all the invariant properties (such as integrity constraints) defined on the data. On completion of a successful transaction, the data should be in a consistent state. In other words, a transaction should transform the system from one consistent state to another consistent state. For example, in the case of relational databases, a consistent transaction should preserve all the integrity constraints defined on the data.
  • ISOLATION: Each transaction should appear to execute independently of other transactions that may be executing concurrently in the same environment. The effect of executing a set of transactions serially should be the same as that of running them concurrently.
  • DURABILITY: The effects of a completed transaction should always be persistent.

These properties, called as ACID properties, guarantee that a transaction is never incomplete, the data is never inconsistent, concurrent transactions are independent, and the effects of a transaction are persistent.

A typical transaction processing architecture includes a transaction manager to implement transactions and preserve the ACID properties of transactions with the help of resource managers. A resource manager is a component that manages persistent and stable data storage systems. The transaction manager implements a protocol known as the two phase commit protocol to preserve the ACID properties. Please refer to Nuts and Bolts of Transaction Processing for a review of various transaction processing concepts and related standards and technologies.

Background

In the distributed transaction management domain, X/Open Distributed Transaction Processing (DTP) model is the most widely adopted model for building transactional applications. Almost all vendors developing products related to transaction processing, relational databases, and message queuing, support the interfaces defined in the DTP model.

This model defines three components: application programs, resource managers, and a transaction manager. This model also specifies functional interfaces between application programs and the transaction manager (known as the TX interface), and between the transaction manager and the resource managers (the XA interface). With products complying to these interfaces, one can implement transactions with the two phase commit and recovery protocol to preserve atomicity of transactions.

Object Transaction Service (OTS) is another distributed transaction processing model specified by the Object Management Group (OMG). This model is based on the X/Open DTP model, and replaces the functional TX and XA interfaces with CORBA IDL interfaces. In this model, the various objects communicate via CORBA method calls over IIOP. Yet, the OTS model is interoperable with the X/Open DTP model. An application using transactional objects could use the TX interface with the transaction manager for transaction demarcation.

As a part of the enterprise Java initiative, Sun Microsystems Inc. proposed the Java Transaction Service and the Java Transaction API in early 1999. Of these, the JTS is still in a draft form (as of May 1999, at version 0.95).

This paper reviews the Java Transaction Service and the Java Transaction API specifications and discusses the underlying architecture. It also discusses various usage scenarios.

Java Transaction Service - Architecture

The Java transaction initiative consists of two specifications: Java Transaction Service (JTS) and Java Transaction API (JTA).

Java Transaction Initiative
Figure 1: Java Transaction Initiative

JTS specifies the implementation of a Java transaction manager. This transaction manager supports the JTA, using which application servers can be built to support transactional Java applications. Internally the JTS implements the Java mapping of the OMG OTS 1.1 specifications. The Java mapping is specified in two packages: org.omg.CosTransactions and org.omg.CosTSPortability.

The JTA specifies an architecture for building transactional application servers and defines a set of interfaces for various components of this architecture. The components are: the application, resource managers, and the application server, as shown in Figure 1.

The JTS thus provides a new architecture for transactional application servers and applications, while complying to the OMG OTS 1.1 interfaces internally. This allows the JTA compliant applications to interoperate with other OTS 1.1 complaint applications through the standard IIOP.

As shown in Figure 1, in the Java transaction model, the Java application components can conduct transactional operations on JTA compliant resources via the JTS. The JTS acts as a layer over the OTS. The applications can therefore initiate global transactions to include other OTS transaction managers, or participate in global transactions initiated by other OTS compliant transaction managers.

The Java Transaction Service is architected around an application server and a transaction manager. The architecture is shown in Figure 2.

JTS Architecture
Figure 2: JTS Architecture

The JTS architecture consists of the following components:

  • Transaction Manager: The transaction manager is the core component of this architecture and is provided by an implementation of the JTS. It provides interfaces to create transactions (including transaction demarcation and propagation of transaction context), allows enlistment and delistment of resources, provides interfaces for registering components for application synchronization, implements the synchronization protocol, and initiates and directs the two phase commit and recovery protocol with the resource managers.
  • Application Server: One of the key features of the JTS architecture is that it allows an application server to be built on top of the transaction service and the resources. Application developers can develop and deploy application components onto the application server for initiating and managing transactions. The application server can therefore abstract all transactional semantics from the application programs.
  • Application Components: These are the clients for the transactional resources and implement business transactions. These are deployed on the application server. Depending on the architecture of the application server, these components can directly or indirectly create transactions and operate on the transactional resources. For example, an Enterprise JavaBean (EJB) server allows declarative transaction demarcation, in which case, the EJB components need not directly implement the transactions. However, a Java implementation of a CORBA OTS, requires the CORBA object to demarcate transactions explicitly.
  • Resource Manager: A resource manager is an X/Open XA compliant component that manages a persistent and stable storage system, and participates in the two phase commit and recovery protocol with the transaction manager. The application manager also provides interfaces for the application server and the application components to operate on the data managed by it.
  • Communication Resource Manager: This allows the transaction manager to participate in transactions initiated by other transaction managers. However, the JTS specification does not specify any protocol for this communication and assumes that an implementation of the communication resource manager supports the CORBA OTS and GIOP specifications.

Java Transaction API

The JTA specification may be classified into three categories of interface as shown in Figure 3. In a JTS implementation, these are provided by the transaction manager, resource manager and the application components respectively.

JTA Interfaces
Figure 3: JTA Interfaces

Transaction Manager Interfaces

  • javax.transaction.Status: Defines the following flags for the status of a transaction:
    Flag Purpose
    STATUS_ACTIVE Transaction is active (started but not prepared).
    STATUS_COMMITTED Transaction is committed.
    STATUS_COMMITTING Transaction is in the process of committing.
    STATUS_MARKED_ROLLBACK Transaction is marked for rollback.
    STATUS_NO_TRANSACTION There is no transaction associated with the current Transaction, UserTransaction or TransactionManager objects.
    STATUS_PREPARED Voting phase of the two phase commit is over and the transaction is prepared.
    STATUS_PREPARING Transaction is in the process of preparing.
    STATUS_ROLLEDBACK Outcome of the transaction has been determined as rollback. It is likely that heuristics exists.
    STATUS_ROLLING_BACK Transaction is in the process of rolling back.
    STATUS_UNKNOWN A transaction exists but its current status can not be determined. This is a transient condition
    Table 1: Transaction Status Flags


    The javax.transaction.Transaction, javax.transaction.TransactionManager, and javax.transaction.UserTransaction interfaces provide a getStatus method that returns one of the above status flags.

  • javax.transaction.Transaction: An object of this type is created for each global transaction. This interface provides methods for transaction completion(commit and rollback), resource enlistment (enlistResource) and delistment (delistResource), registration of synchronization objects (registerSynchronization), and query of status of the transaction (getStatus).
  • javax.transaction.TransactionManager: This interface is implemented by the JTS and allows an application server to communicate with the transaction manager to demarcate transactions (begin, commit, rollback, suspend and resume), set the transaction for rollback (setRollbackOnly), get the associated Transaction object (getTransaction), set the transaction timeout interval (setTransactionTimeout) and query the status of the transaction (getStatus).
  • javax.transaction.UserTransaction: This interface allows application components to manage transaction boundaries explicitly. This interface provides methods to begin and end transactions (begin, commit, and rollback), set the transaction for rollback (setRollbackOnly), set the transaction timeout interval (setTransactionTimeout), and get the status of the transaction (getStatus). The application server should provide an interface to create an object of this type.
  • javax.transaction.xa.Xid: This interface is a Java mapping of the X/Open transaction identifier xid structure. The transaction manager uses an object of this type to associate a resource manager with a transaction.

Resource Manager Interfaces

  • javax.transaction.xa.XAResource: This is a Java mapping of the X/Open XA interface, and is implemented by resource managers operating with the JTS. This interface provides methods to start (start) and end (end) work on behalf of a specified transaction, to prepare a transaction with the current resource (prepare), to end transactions with the current resource (commit, forget, recover, and rollback), to compare the current resource manager with another resource manager (isSameRM), and to get and set the transaction timeout (getTransactionTimeout, setTransactionTimeout).

Application Interfaces

The only interface that an application object could implement is the Synchronization interface. The application components may have to implement whatever other interfaces are mandated by a given application server.

  • javax.transaction.Synchronization: An object intended to participate in a synchronization protocol with the transaction manager should implement this interface. This mechanism is based on the Observer pattern. This interface has two methods - beforeCompletion and afterCompletion to be called before starting and after completing, respectively, the two phase commit operation.

Java Transaction API - Usage

This section describes the usage of the JTA for implementing various transaction semantics. The purpose of this section is to provide conceptual guidelines only.

Transaction Demarcation

Transaction demarcation enables work done by distributed components to be bound by a global transaction. The JTA specifies two approaches with which new global transactions can be initiated and demarcated.

  1. Programmatic Demarcation: The javax.transaction.UserTransaction interface provides methods for application components to begin and end transactions programmatically. The underlying application server should provide a mechanism to obtain a reference to this object. The JTA specification requires that the application servers use the JNDI for storing references to UserTransaction objects and for lookup.

    The application component can then use this object to begin, commit and rollback transactions.

    In this approach, association between the calling thread and the transaction, and transaction context propagation are handled transparently by the transaction manager.

    Usage

    // Get a UserTransaction object
    // Begin a transaction
    userTransaction.begin();

    // Transactional operations ...

    // End the transaction
    userTransaction.commit();

  2. Application Server Controlled Demarcation In this approach, the javax.transaction.TransactionManager interface controls transaction demarcation on behalf of the application being managed. The transaction manager also maintains the transaction context and its association with the calling threads implicitly.

    Usage

    // Begin a transaction
    Transaction t = TransactionManager.begin();

    // Transactional operations ...

    // End the transaction
    TransactionManager.commit();

Transaction Context

Transaction context is an association between the transactional operations on the resources, and the objects invoking these operations. During the course of a transaction, the transaction context is shared by all objects participating in the transaction. Thus, the transaction context logically envelopes all the operations performed on transactional resources during the course of a transaction.

The javax.transaction.Transaction object encapsulates the transaction context information. This object can be used to perform transaction specific operations irrespective of the calling thread's transaction context.

In JTS, the transaction context propagation is managed by the underlying implementation of the transaction manager.

Resource Enlistment and Delistment

Resource enlistment is the process by which resource managers are registered with the transaction manager for their participation in the transaction. This process enables the transaction manager to keep track of the all the resource managers participating in a transaction. The transaction manager uses this information to coordinate transactional work performed by the resource managers, and to drive the two phase commit and recovery protocol.

Using the javax.transaction.Transaction interface, the application server can enlist and delist resource managers with the transaction manager.

Usage

Resource enlistment is done by the application server when an application requests it for a connection to a transactional resource.

// ... an implementation of the application server
// Get a reference to the underlying TransactionManager object.
...
// Get the current Transaction object from the TransactionManager.
transaction = transactionManager.getTransaction();
// Get an XAResource object from a transactional resource.
...
// Create a Transaction object.
...
// Enlist the resource
transaction.enlistResource(xaResource);
...
// Return the connection to the application.
..

Resource delistment is done similarly after the application closes connections to transactional resources.

Application Synchronization with a Transaction

Using the JTS synchronization protocol, certain objects can be registered with the transaction manager for notification before the start of and the completion of the two-phase commit process. This enables such application objects to synchronize transient state and data stored in persistent storage.

The javax.transaction.Transaction interface provides a method to register javax.transaction.Synchronization objects with the transaction manager. The transaction manager then uses the synchronization protocol and calls the beforeCompletion and afterCompletion methods before and after the two phase commit process.

Application objects can be registered for synchronization using the registerSynchronization method of the Transaction interface.

Two Phase Commit

This protocol between the transaction manager and all the resources enlisted ensures that either all the resource managers commit the transaction, or they all abort.

The first phase of this protocol is the preparation phase, during which the transaction manager conducts a voting among all the resource managers registered for the target transaction. The transaction manager calls the prepare method on each resource manager, which will return a X_READONLY or XA_OK constant. The first value implies that the operations conducted on the target resource are read only, and there are no operations to be committed. The second value indicates that the resource manager is ready to commit the operations. In case the resource manager wants the transaction to be rolled back, it throws an appropriate XAException.

The second phase is a commit or recover phase. Depending on whether all resource managers are ready for a commit or not, one of these phases will be invoked by the transaction manager.

In case all the resource managers return a X_OK in the first phase, the transaction manager calls the commit method on each resource manager. Please note that the two phase protocol is not fool-proof, and the commit calls may throw appropriate XAException in return. In such a case, the transaction manager should initiate the recovery phase.

In case the voting determines a rollback, the transaction calls the recover on each prepared resource manager.

Conclusion

This article introduces the JTS and JTA, the architecture, and how some of the transaction processing semantics could be implemented in a JTS application environment.

The JTS and JTA are the latest entrants into the enterprise distributed computing arena. Although the JTS is a Java implementation of the OMG OTS 1.1 specification, the JTA retains the simplicity of the XA and TX functional interfaces of the X/Open DTP model.

At the time of writing this article, object transaction processing products complying to the JTS and JTA are yet to appear, although Integrated Transaction Service (from Inprise), JTSArjuna (from Arjuna Solutions Limited), and TPBroker (from Hitachi Software) implement the Java mapping (JTS) of the OTS 1.1 specification. However, the JTA is more relevant in the context of application servers such as EJB application servers. Currently EJB application servers compliant to entity beans implement the JTS and JTA interfaces.

__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

New web site?

Drive traffic now.

Get your business

on Yahoo! search.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Posted by at No comments:
Subscribe to: Posts (Atom)