Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Enterprise JavaBeans™ Specification, Version 2.0 - Sun Microsystems.pdf
Скачиваний:
14
Добавлен:
24.05.2014
Размер:
2.71 Mб
Скачать

Sun Microsystems Inc

Sample scenarios

Enterprise JavaBeans 2.0, Public Draft

Support for Transactions

Note: The decision not to support nested transactions allows vendors of existing transaction processing and database management systems to incorporate support for Enterprise JavaBeans. If these vendors provide support for nested transactions in the future, Enterprise JavaBeans may be enhanced to take advantage of nested transactions.

16.1.3 Relationship to JTA and JTS

The Java™ Transaction API (JTA) [5] is a specification of the interfaces between a transaction manager and the other parties involved in a distributed transaction processing system: the application programs, the resource managers, and the application server.

The Java Transaction Service (JTS) [6] API is a Java binding of the CORBA Object Transaction Service (OTS) 1.1 specification. JTS provides transaction interoperability using the standard IIOP protocol for transaction propagation between servers. The JTS API is intended for vendors who implement transaction processing infrastructure for enterprise middleware. For example, an EJB Server vendor may use a JTS implementation as the underlying transaction manager.

The EJB architecture does not require the EJB Container to support the JTS interfaces. The EJB architecture requires that the EJB Container support the JTA API defined i n [ 5 ] and the Connector APIs defined in [ 11 ].

16.2 Sample scenarios

This section describes several scenarios that illustrate the distributed transaction capabilities of the Enterprise JavaBeans architecture.

16.2.1 Update of multiple databases

The Enterprise JavaBeans architecture makes it possible for an application program to update data in multiple databases in a single transaction.

In the following figure, a client invokes the enterprise Bean X. Bean X updates data using two database connections that the Deployer configured to connect with two different databases, A and B. Then X calls another enterprise Bean Y. Bean Y updates data in database C. The EJB Server ensures that the updates to databases A, B, and C are either all committed or all rolled back.

301

5/31/00

Sun Microsystems Inc.

Support for Transactions

Enterprise JavaBeans 2.0, Public Draft

Sample scenarios

Figure 65 Updates to Simultaneous Databases

client

EJB Server

 

X Y

database A database B database C

The application programmer does not have to do anything to ensure transactional semantics. The enterprise Beans X and Y perform the database updates using the standard JDBC™ API. Behind the scenes, the EJB Server enlists the database connections as part of the transaction. When the transaction commits, the EJB Server and the database systems perform a two-phase commit protocol to ensure atomic updates across all three databases.

16.2.2 Messages sent or received over JMS sessions and update of multiple databases

The Enterprise JavaBeans architecture makes it possible for an application program to send messages to or receive messages from one or more JMS Destinations and/or to update data in one or more databases in a single transaction.

In the following figure, a client invokes the enterprise Bean X. Bean X sends a message to a JMS queue A and updates data in a database B using connections that the Deployer configured to connect with a JMS provider and a database. Then X calls another enterprise Bean Y. Bean Y updates data in database C. The EJB Server ensures that the operations on A, B, and C are either all committed, or all rolled back.

5/31/00

302

Sun Microsystems Inc

Sample scenarios

Enterprise JavaBeans 2.0, Public Draft

Support for Transactions

Figure 66 Message sent to JMS queue and updates to multiple databases

client

EJB Server

 

X Y

queue A database B database C

The application programmer does not have to do anything to ensure transactional semantics. The enterprise Beans X and Y perform the message send and database updates using the standard JMS and JDBC™ APIs. Behind the scenes, the EJB Server enlists the session on the connection to the JMS provider and the database connections as part of the transaction. When the transaction commits, the EJB Server and the messaging and database systems perform a two-phase commit protocol to ensure atomic updates across all the three resources.

In the following figure, a client sends a message to the JMS queue A serviced by the message-driven Bean X. Bean X updates data using two database connections that the Deployer configured to connect with two different databases, B and C. The EJB Server ensures that the dequeueing of the JMS message, its receipt by Bean X, and the updates to databases B and C are either all committed or all rolled back.

303

5/31/00

Sun Microsystems Inc.

Support for Transactions

Enterprise JavaBeans 2.0, Public Draft

Sample scenarios

Figure 67 Message sent to JMS queue serviced by message-driven bean and updates to multiple databases

client

EJB Server

queue A

 

X

database B

database C

16.2.3 Update of databases via multiple EJB Servers

The Enterprise JavaBeans architecture allows updates of data at multiple sites to be performed in a single transaction.

In the following figure, a client invokes the enterprise Bean X. Bean X updates data in database A, and then calls another enterprise Bean Y that is installed in a remote EJB Server. Bean Y updates data in database B. The Enterprise JavaBeans architecture makes it possible to perform the updates to databases A and B in a single transaction.

Figure 68 Updates to Multiple Databases in Same Transaction

client

EJB Server

EJB Server

 

 

 

X

Y

database A

database B

5/31/00

304