- Building the Architectural Prototype: Part 1
- Building the Architectural Prototype: Part 2
- Building the Architectural Prototype: Part 3
- Checkpoint
This chapter is from the book
This chapter is from the book
This chapter is from the book
Building the Architectural Prototype: Part 2
Part 2 of building the architectural prototype for our non-EJB solution covers the use-case control class and the issues of transaction management.
Remulak Controllers and Initial Operations
The Remulak software architecture uses two types of controllers: user interface and use-case. In the previous section we covered the user interface aspects that the controller handles for us—namely, the servlet.
In this section we cover the use-case control class: UCMaintainRltnshp. To reemphasize our strategy, each use-case will have a use-case control class. Each use-case control class will have an operation for each happy and alternate pathway in the use-case. Occasionally, depending on the granularity of the use-case, some of the alternates may be handled in the course of either the happy path or one of the other alternates. Exceptions are always handled in the course of another pathway.
UCMaintainRltnshp is a JavaBean in this first analysis of use-case controllers. In Chapter 12 the same class will be made into a session EJB. However, the operation names and what they do will remain identical. Let's review, as we did with RemulakServlet, the various parts of the use-case control class, starting with the class definition and the rltnCustomerInquiry() operation referred to in the previous section:
package com.jacksonreed;
import java.util.Enumeration;
import java.util.Random;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.naming.NamingException;
public class UCMaintainRltnshp implements
java.io. Serializable {
private static Random generator;
private static TransactionContext transactionContext;
public UCMaintainRltnshp() {
transactionContext = new TransactionContext();
}
public CustomerValue rltnCustomerInquiry(String
customerNumber){
CustomerValue customerValue = new CustomerValue();
CustomerBean customerHome = new CustomerBean();
try {
transactionContext.beginTran(false);
customerValue = CustomerHome.findByCustomerNumber
(transactionContext, customerNumber);
transactionContext.commitTran();
} catch (RemulakFinderException fe) {
} catch (TranCommitException ce) {
} catch (TranSysException se) {
} catch (TranBeginException be) {
} catch (TranRollBackException re) {
} catch (Exception e) {
} finally {
customerHome = null;
}
return customerValue;
}
}
The rltnCustomerInquiry() operation begins by instantiating a CustomerBean object. This step is necessary because, as you may recall, the use-case controller is akin to the conductor of an orchestra; in this case the orchestra is the use-case, and the musicians are the individual objects involved in the score. A use-case controller may send messages to only one bean or to many beans, depending on the needs of the use-case pathway. The operation then invokes beginTran() on an object called TransactionContext (more on this shortly). The CustomerBean object is sent a findByCustomerNumber() message, with both the TransactionContext object and the customerNumber attribute passed in. The result returned from this operation is our populated Customer Value object.
The last thing that happens in this use-case pathway operation is that the TransactionContext object receives a commitTran() request. The rest continues with what we saw in the previous section: RemulakServlet now has the CustomerValue object, and the JSP does its work, filling the screen with information for the user. However, the Transaction Context object needs more discussion.
Remulak Transaction Management: Roll Your Own
Transaction management is key to any software application today. In particular, it is vital for update activity when more than one set of updates is occurring, all part of a package of updates. This package of updates is called a unit of work in transaction terminology. How does transaction management work and how do we code for it? Here's one of the big drawbacks to not using a commercial container product that implements the EJB framework. If the application is using just native JDBC, the software developer is responsible for all transaction management activities.
Where to put the transaction logic is a problem. However, the beauty of the design strategy we are following (a controller for each use-case and an operation for each pathway) is that management of the unit of work must begin in the use-case control class. We can't put the begin/ commit logic in the DAO classes because many DAO classes may be involved in one unit of work. We also can't put the begin/commit logic in the entity bean classes because they are in the same boat as the DAO classes: They represent just one musician playing in the orchestra of the use-case pathway. So figuring out where to manage the transaction seems logical, but the architecture of it isn't.
We need a class that can load JDBC drivers, manage connection pools, and open database connections. We need a class that can begin a transaction as well as commit it. This is what the TransactionContext class will do for us. To be able to roll back a transaction, all SQL activity must happen on the same connection. The connection's life span is usually parallel to that of the unit of work. So the TransactionContext object must be passed into the entity bean classes and then into the DAO classes. This same requirement applies to all entity beans involved in a unit of work.
Let's examine the TransactionContext class:
import java.io.*;
import java.sql.*;
import java.text.*;
import java.util.*;
import javax.sql.*;
public class TransactionContext implements Serializable {
private Connection dbConnection = null;
private DataSource datasource = null;
private CustomerValue custVal = null;
private boolean unitOfWork = false;
public TransactionContext() {
try {
// This is where we load the driver
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
}
catch (ClassNotFoundException e) {
System.out.println("Unable to load Driver Class");
throw new TranSysException(e.getMessage());
}
}
Note first that the constructor is where the driver is loaded for our database. Again, wanting to stick with the semantics of what is happening versus additional abstractions, I'll say simply that it is done in a very manual way. A better solution would be to use JNDI or perhaps a .properties file to look up the driver name instead of hard-coding it in the constructor.
public Connection getDBConnection() {
log("TransactionContext: in get connection");
if (dbConnection == null)
throw new TranSysException
("no database connection established
yet");
return dbConnection;
}
public void beginTran(boolean supportTran)
throws TranBeginException, TranSysException {
unitOfWork = supportTran;
getConnection();
try {
if (supportTran) {
dbConnection.setAutoCommit(false);
}
else {
dbConnection.setAutoCommit(true);
}
}
catch (SQLException e) {
throw new TranBeginException(e.getMessage());
}
}
The beginTran() operation receives a boolean input parameter. This boolean tells the operation if a unit of work is necessary, meaning that updates are going to occur. The next element of beginTran() is to call its getConnection() operation:
public void getConnection() throws TranSysException {
try {
dbConnection = DriverManager.getConnection
("jdbc:odbc:remulak-bea","", "");
} catch (SQLException se) {
throw new TranSysException("SQLExcpetion while
getting" +
" DB Connection : \n" + se);
}
}
A getConnection() call to the DriverManager object created in the constructor establishes a connection with the driver loaded previously, by use of the data source name necessary to talk to the database. Again, it would be an added benefit to load this driver with JNDI.
Back to beginTran(), if a unit of work is necessary, false is passed to the setAutoCommit() method; otherwise each individual update request would be committed as it occurred. If this is a read-only type of request, true (the default) is passed to setAutoCommit().
public void commitTran()
throws TranCommitException, TranSysException,
TranRollBackException {
if (unitOfWork) {
try {
dbConnection.commit();
}
catch (SQLException e) {
rollBackTran();
throw new TranCommitException("Can't commit
transaction");
}
}
closeConnection();
}
When committing work, TransactionContext knows from the initial call to beginTran() whether a unit of work is under way; if so, a commit is issued on the connection and the connection is closed. If no unit of work is under way, the connection is simply closed.
The remaining operations in the TransactionContext class follow. Some of the operations, such as closeResultSet() and close Statement(), will be used by the DAO classes that will be reviewed later in this chapter.
public boolean rollBackTran()
throws TranRollBackException, TranSysException {
boolean returnValue = false;
try {
dbConnection.rollback();
closeConnection();
returnValue = true;
}
catch (SQLException e) {
throw new TranRollBackException("Can't roll back
transaction");
}
return returnValue;
}
public void closeResultSet(ResultSet result)
throws TranSysException {
try {
if (result != null) {
result.close();
}
}
catch (SQLException se) {
throw new TranSysException("SQL Exception while
closing " + "Result Set : \n" + se);
}
}
public void closeStatement(Statement stmt)
throws TranSysException {
try {
if (stmt != null) {
stmt.close();
}
} catch (SQLException se) {
throw new TranSysException("SQL Exception while
closing " + "Statement : \n" + se);
}
}
public void closeConnection() throws TranSysException {
try {
if (dbConnection != null && !dbConnection.isClosed()) {
dbConnection.close();
log("TransactionContext: closing connection");
}
} catch (SQLException se) {
throw new TranSysException("SQLException while closing"
+ " DB Connection : \n" + se);
}
}
}
The TransactionContext class allows us to encapsulate all the transaction management logic in one place. It also makes it convenient because each controller pathway operation can use the same syntax. It is true that read-only operations don't begin and commit transactions, but we have abstracted out the underlying functionality by simply indicating the intent with the beginTran() call at the beginning of the interaction.
Remulak Controllers and Subsequent Operations
Let's continue with the UCMaintainRltnshp control class by looking at the rltnAddCustomer() operation. For add operations, a primary key must be assigned. The relevant code follows, but it simply uses the Random class out of the java.util package. You can build more industrial-strength generators, but this one will serve our purpose.
public void rltnAddCustomer(CustomerValue custVal) {
// Seed random generator
seedRandomGenerator();
// Generate a random integer as the key field
custVal.setCustomerId(generateRandomKey());
CustomerBean customerHome = new CustomerBean();
try {
transactionContext.beginTran(true);
customerHome.customerInsert(transactionContext,
custVal);
transactionContext.commitTran();
} catch (RemulakFinderException fe) {
} catch (TranCommitException ce) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} catch (TranSysException se) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} catch (TranBeginException be) {
} catch (TranRollBackException re) {
} catch (Exception e) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} finally {
customerHome = null;
}
}
private static void seedRandomGenerator() {
generator = new Random(System.currentTimeMillis());
}
private Integer generateRandomKey() {
Integer myInt = new Integer(generator.nextInt());
return myInt;
}
The fact that beginTran() is now passed a value of true indicates that there is a unit-of-work requirement for this transaction. In the try/catch blocks we see how rollBackTran() is called within TransactionContext if there are problems along the way.
The remaining operations of the UCMaintainRltnshp class follow. In Chapter 12 we'll see that this class also covers the pathways of adding roles and addresses.
public void rltnUpdateCustomer(CustomerValue custVal) {
CustomerBean customerHome = new CustomerBean();
try {
transactionContext.beginTran(true);
customerHome.customerUpdate(transactionContext,
custVal);
transactionContext.commitTran();
} catch (RemulakFinderException fe) {
} catch (TranCommitException ce) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} catch (TranSysException se) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} catch (TranBeginException be) {
} catch (TranRollBackException re) {
} catch (Exception e) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} finally {
customerHome = null;
}
}
public void rltnDeleteCustomer(Integer customerId) {
CustomerBean customerHome = new CustomerBean();
try {
transactionContext.beginTran(true);
customerHome.customerDelete(transactionContext,
customerId);
transactionContext.commitTran();
} catch (RemulakFinderException fe) {
} catch (TranCommitException ce) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} catch (TranSysException se) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} catch (TranBeginException be) {
} catch (TranRollBackException re) {
} catch (Exception e) {
try {
transactionContext.rollBackTran();
}
catch (TranRollBackException ree) {
}
} finally {
customerHome = null;
}
}