web server - Borland Technical Publications
web server - Borland Technical Publications web server - Borland Technical Publications
Transaction manager services The following diagrams show example interactions between the client, the BES Partition, and how the BES Partition locates the right transaction service based on the above configuration. All of the beans are assumed to have container-managed transactions. Example 1PC usage 1 The client calls a method of UserSesEJB. This is an implementation of the method that creates users in the database. 2 Before the call is actually invoked, as shown below, the Partition uses its in-process Transaction Manager to begin the transaction. 3 The session bean does some database work. 4 When the call is over, the Partition issues commit. 5 The Transaction Manager calls commit_one_phase() on the database resource. Figure 19.1 Example of 1PC usage Example 2PC usage 1 The client calls OrderSesEJB.create() method to create a new order. 2 Since the bean is configured to use the OTS engine named TwoPhaseEngine, the container locates the right transaction service named TwoPhaseEngine, and uses it for beginning the transaction. 3 The session bean does some database work, and sends a message to a JMS queue. 4 When the call is over, the Partition issues commit. 5 The OTS engine coordinates the transaction completion with the database and the JMS resources. Chapter 19: Transaction management 173
Declarative transaction management in Enterprise JavaBeans Figure 19.2 Example of 2PC usage Example 2PC usage with MDBs At some point in time, an asynchronous message is delivered to OrderCompletionMDB by invoking its onMessage() method, which has a REQUIRED transaction attribute. The container starts a transaction using ITS and then invokes the onMessage() method. In the body of the method, the bean updates the database to indicate order delivery. It is important to note that there are 2 resources involved. The first one is the JMS resource, which is associated with the MDB instances that got the message, and the second is the database that the MDB instance updated. This scenario is similar to the example diagram above. Note ejb.transactionManagerInstanceName is also supported for MDBs. See Chapter 20, “Message-Driven Beans and JMS” for more information. Declarative transaction management in Enterprise JavaBeans Transaction management for Enterprise JavaBeans (EJBs) is handled by the EJB Container and the EJBs. Enterprise JavaBeans make it possible for applications to update data in multiple databases within a single transaction. EJBs utilize a declarative style of transaction management that differs from the traditional transaction management style. With declarative management, the EJB declares its transaction attributes at deployment time. The transaction attributes indicate whether the EJB container manages the bean's transactions or whether the bean itself manages its own transactions, and, if so, to what extent it does its own transaction management. Traditionally, the application was responsible for managing all aspects of a transaction. This entailed such operations as: ■ ■ ■ ■ ■ Creating the transaction object. Explicitly starting the transaction. Registering resources involved in the transaction. Keeping track of the transaction context. Committing the transaction when all updates completed. It requires a developer with extensive transaction processing expertise to write an application that is responsible for managing a transaction from start to finish. The code for such an application is more complex and difficult to write, and it is easy for “pilot error” to occur. 174 BES Developer’s Guide
- Page 133 and 134: Setting Properties into a BLOB. The
- Page 135 and 136: Setting Properties Automatic table
- Page 137 and 138: 126 BES Developer’s Guide
- Page 139 and 140: Container-managed persistence and R
- Page 141 and 142: Container-Managed Persistence in Bo
- Page 143 and 144: Container-Managed Persistence in Bo
- Page 145 and 146: Container-Managed Persistence in Bo
- Page 147 and 148: Container-Managed Persistence in Bo
- Page 149 and 150: Container-Managed Persistence in Bo
- Page 151 and 152: Container-Managed Persistence in Bo
- Page 153 and 154: 142 BES Developer’s Guide
- Page 155 and 156: Setting Properties J2EE 1.3 Entity
- Page 157 and 158: Setting Properties Figure 16.2 Edit
- Page 159 and 160: Setting Properties Table 16.1 ejb.m
- Page 161 and 162: Setting Properties Table 16.3 Table
- Page 163 and 164: Setting Properties Security Propert
- Page 165 and 166: Aggregate Functions in EJB-QL Selec
- Page 167 and 168: Support for ORDER BY Support for OR
- Page 169 and 170: Overriding SQL generated from EJB-Q
- Page 171 and 172: Container-managed data access suppo
- Page 173 and 174: 162 BES Developer’s Guide
- Page 175 and 176: Generating primary keys from a cust
- Page 177 and 178: Implementing primary key generation
- Page 179 and 180: Transaction manager services Consis
- Page 181 and 182: Transaction manager services When t
- Page 183: Transaction manager services Follow
- Page 187 and 188: Declarative transaction management
- Page 189 and 190: JDBC API Modifications JDBC API Mod
- Page 191 and 192: Handling of EJB exceptions Applicat
- Page 193 and 194: 182 BES Developer’s Guide
- Page 195 and 196: Client View of an MDB Client View o
- Page 197 and 198: Clustering of MDBs This is yet anot
- Page 199 and 200: Error Recovery Redelivered messages
- Page 201 and 202: 190 BES Developer’s Guide
- Page 203 and 204: JNDI Definitions Module Important s
- Page 205 and 206: Disabling and Enabling a Deployed D
- Page 207 and 208: Configuring JDBC Datasources In the
- Page 209 and 210: Configuring JDBC Datasources To add
- Page 211 and 212: Defining the Connection Pool Proper
- Page 213 and 214: Defining the Connection Pool Proper
- Page 215 and 216: Descriptions of Borland Enterprise
- Page 217 and 218: Advanced Topics for Defining JDBC D
- Page 219 and 220: Connecting to JDBC Resources from J
- Page 221 and 222: Configuring JMS Connection Factorie
- Page 223 and 224: Defining Connection Pool Properties
- Page 225 and 226: Obtaining JMS Connection Factories
- Page 227 and 228: JMS and Transactions and its accomp
- Page 229 and 230: JMS and Transactions For instance:
- Page 231 and 232: 220 BES Developer’s Guide
- Page 233 and 234: Configuring JMS administered object
Declarative transaction management in Enterprise JavaBeans<br />
Figure 19.2<br />
Example of 2PC usage<br />
Example 2PC usage with MDBs<br />
At some point in time, an asynchronous message is delivered to OrderCompletionMDB by<br />
invoking its onMessage() method, which has a REQUIRED transaction attribute. The<br />
container starts a transaction using ITS and then invokes the onMessage() method. In<br />
the body of the method, the bean updates the database to indicate order delivery. It is<br />
important to note that there are 2 resources involved. The first one is the JMS<br />
resource, which is associated with the MDB instances that got the message, and the<br />
second is the database that the MDB instance updated. This scenario is similar to the<br />
example diagram above.<br />
Note ejb.transactionManagerInstanceName is also supported for MDBs. See Chapter 20,<br />
“Message-Driven Beans and JMS” for more information.<br />
Declarative transaction management in Enterprise JavaBeans<br />
Transaction management for Enterprise JavaBeans (EJBs) is handled by the EJB<br />
Container and the EJBs. Enterprise JavaBeans make it possible for applications to<br />
update data in multiple databases within a single transaction.<br />
EJBs utilize a declarative style of transaction management that differs from the<br />
traditional transaction management style. With declarative management, the EJB<br />
declares its transaction attributes at deployment time. The transaction attributes<br />
indicate whether the EJB container manages the bean's transactions or whether the<br />
bean itself manages its own transactions, and, if so, to what extent it does its own<br />
transaction management.<br />
Traditionally, the application was responsible for managing all aspects of a transaction.<br />
This entailed such operations as:<br />
■<br />
■<br />
■<br />
■<br />
■<br />
Creating the transaction object.<br />
Explicitly starting the transaction.<br />
Registering resources involved in the transaction.<br />
Keeping track of the transaction context.<br />
Committing the transaction when all updates completed.<br />
It requires a developer with extensive transaction processing expertise to write an<br />
application that is responsible for managing a transaction from start to finish. The code<br />
for such an application is more complex and difficult to write, and it is easy for “pilot<br />
error” to occur.<br />
174 BES Developer’s Guide