Managing Transaction Scope

An application that will interact with any type of data repository can face the somewhat daunting task of managing the transaction scope. Transaction scope is the entire process of establishing a database connection, communicating with the resource at the end of the connection, eventually committing any changes made, and then closing the connection.

Managing transaction scope is more difficult if the scope crosses physical database boundaries. For example, suppose that a transaction must update both an Oracle database and a Microsoft SQL Server database within the scope of one transaction and ensure that both servers are updated at the end of the transaction. This is difficult to do because talking to each database product (Oracle and SQL Server) requires a connection to each that must be managed individually with respect to their individual commit scope. Figure 8-5 depicts a transaction scenario between two database products.

One solution to this problem is to use a transaction monitor. A transaction monitor, such as BEA's Tuxedo, acts as a watchdog over any utilized resources and is delegated the task of monitoring transaction scope. However, transaction monitors are substantial overkill for small to medium-sized shops.

Another option is to utilize the services of plain JavaBeans coded to utilize JDBC and its ability to control transactions. In JDBC we can quite easily define a unit of work by beginning a transaction: that is, setting the auto-commit parameter of the JDBC connection to false, performing as many update-type transactions as desired, and then issuing a commit or rollback command on the connection. For Remulak Productions, this will be an initial solution that we present in a later chapter.

The final solution discussed here utilizes Enterprise JavaBeans running inside of an application server product. EJB is the framework offered by Sun Microsystems and implemented by many EJB vendors—such as BEA with its WebLogic product, and IBM with its WebSphere product—that provide for true enterprise-level transaction support. There are also open-source (i.e., free!) EJB servers, such as JBoss (found at www.jboss.org). For Remulak Productions, an EJB solution will be a second option that we present in a later chapter.

Enterprise JavaBeans

Two primary types of beans are at play in an EJB container. The first type consists of session beans, which can be thought of as workflow coordinators or utility services. The second type consists of entity beans, which represent the entity classes we have already discussed.

Managing transactions is just a small portion of what EJB can do for the application. EJB is reviewed in detail in Chapter 12. For now, the following are some of the many other problems that EJB addresses:

• Database connection pooling: EJB can pool database connections. Sadly, many developers write poor code and in the scope of just one transaction end up with several database connections open to a database. Not only does this waste precious memory resources on the client and server; it can also increase the project's cost if the database vendor is charging per connection. Pooling keeps used connections intact (to the programmer they appear closed), providing the ability to resurrect them as needed.

• Thread pooling: Each component can be written as if it were single-threaded. EJB actually disallows thread management by the application, so you may not use the keyword synchronized; EJB will take care of the rest. EJB also leaves threads open, preallocated, to allow for quicker response to clients that request thread activation.

• Reduction of transaction management logic: Without EJB, each transaction must explicitly issue a “begin” transaction and an “end” transaction. In addition, the application must deal with a myriad of return code checks and error handling pertaining to the database with which it is interfacing. EJB takes care of this by virtually connecting transaction components via a common transaction context.

  Note

  If bean-managed transactions are used within EJB, the beans can still issue their own commit and rollback requests. With Remulak, however, we will use container-managed transactions.

  
  

• Flexible security model: EJB offers a flexible security model for the application's implementation via its deployment descriptor. Users can be assigned to roles, and then those roles can be assigned to components and interfaces within the components.

• Container-managed persistence: EJB versions 1.1 and 2.0 support container-managed persistence. Building and managing SQL statements and their interaction with the underlying database require quite a bit of effort on the part of the application team. Container-managed persistence (CMP) delegates the generation of SQL and the management of basic CRUD (create, read, update, delete) functionality to the EJB framework and the application server that implements the framework (e.g., BEA's WebLogic, IBM's WebSphere, Inprise's Application Server, to name a few). For Remulak we will show an EJB 2.0 implementation of CMP.

EJB can obviously assist the application in reducing the amount of overhead logic and transaction management plumbing. So to provide a perspective, Remulak will provide both a bean-managed persistence (BMP) implementation and a container-managed persistence (CMP) implementation. Both the BMP and the CMP examples will use container-managed transactions.

Once you have seen the additional advantages of using CMP in the EJB environment, it will be hard to use anything else. Just the simple fact of not having to write one line of SQL code is reason enough to jump on the CMP bandwagon. Unfortunately, at the time of this writing very few application server vendors support the EJB 2.0 specification. This is the primary reason why we have chosen BEA's WebLogic, because it was one of the early supporters. By the time this book reaches you, most vendors will be in compliance with the EJB 2.0 specification. The direction and emphasis in the Java community and the emphasis that Sun places on the technology attests to the fact that EJB will continue to be integrated into core product architectures.