Tutorials : Managing DAO Transactions in Java :

Managing DAO Transactions in Java

My recent article, "Using DAOs in Apache Struts" described how to use the DAO design pattern in various application types—Java main applications as well as servlet applications, implemented using Apache Struts, for example. This article's focus will be on some of the more advanced situations a developer faces when using DAOs, starting with transactions.

A transaction is a series of operations, or actions, that either must be entirely completed without failures, or none must be completed. Coding proper transaction handling using a given back-end system, for example, a database, is by no means trivial. Luckily for us, most back-end systems come with ready-to-use modules for transaction handling, so it's simply a matter of understanding and using these modules correctly.

If you're fond of frameworks like Hibernate or Spring, you don't need to know how to implement transactions, since the frameworks may handle them for you. Most developers, however, will need to know the basics of transaction handling in order to use frameworks correctly or when debugging system errors.

Before you explore the details of transaction handling, it's important to look at the various layers of a DAO application and the purpose of each layer.

The code examples presented below use the same classes as in the previous Struts article, and all code may be downloaded here.

The DAO Layer

DAOs form a simple, thin layer to the back-end system. The most important characteristics are:

The nature of the back-end must not be visible in the DAO API. The reason is that one of the main benefits of the DAO pattern is to make it possible to replace the back-end system without affecting the front-end code.
The API should be simple to use and should use standardized names to be helpful to the developers. Typical names for methods could be: create, update, delete, and find.
They should not contain any form for business logic.
They should not call each other. It's always important to keep the number and types of module dependencies as low as possible.
They should avoid keeping any form for "state". A DAO should simply be thought of as the communication bridge to the back-end.
They should be able to participate in transactions. But they should not initiate or terminate transactions.

Since a DAO must be able to implement various back-end systems, it's common practice to let every DAO implement a specific Java Interface. Furthermore, to be able to easily shift from one DAO implementation to another, it's also a good practice to let "factory" classes generate the DAO instances. "Using DAOs in Apache Struts" contains coding examples to show you how this is being done.

The Transaction Handler Layer

Since the DAOs are only simple facades for the back-end, something intelligent is needed in front of them. This is where the Transaction Handlers come into play. You could also call these modules "supervisors" or "managers," there is—to my knowledge—no standardized name for this layer. It's important to emphasize what this layer's role is:

Handlers use DAOs to implement business functions.
They manage transactions—meaning that they should mark the beginnings and endings of transactions and take responsibility for handling errors during transaction execution.
A handler should have a user-friendly API. The users of handlers—their clients—are the front-end part of the application, which could be a browser application, Swing code, etc. A typical scenario is that a client has received a request from the GUI, and now wants to pass it on to the back-end. Handlers should offer methods that take these requests, and their associated data (which typically is string data), perform validation on the data (if the client wishes so), make the DAO calls, and transform the data received from the back-end to data that is useful to the clients.
Handlers should not contain any client-specific code. Methods should not use Swing-related data or servlet objects, like the servlet request and response objects.
Handlers should, of course, not contain anything back-end-specific, like SQL Connection objects.

Home / Articles / Managing DAO Transactions in Java / 1

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.