Chapter 11. Accessing a Database 177 This is very similar to the examples in Chapter 8. The difference is that a separate page does the validation, creating all error messages as request scope variables that are then used in the input page if they exist, instead of conditionally adding error messages defined in the input page. Which approach is best is a matter of preference. 11.3 Using Transactions There's one important database feature we have not discussed yet. In the examples in this chapter, only one SQL statement is needed to complete all database modifications for each request. This statement either succeeds or fails. However, sometimes you need to execute two or more SQL statements in sequence to update the database. A typical example is transferring money between two accounts; one statement removes some amount from the first account, and another statement adds the same amount to the second account. If the first statement is successful, but the second one fails, you have performed a disappearance act your customers aren't likely to applaud. The solution to this problem is to group all related SQL statements into what is called a transaction. A transaction is an atomic operation, so if one statement fails, they all fail; otherwise, they all succeed. This is referred to as committing (if it succeeds) or rolling back (if it fails) the transaction. If there's a problem in the middle of a money transfer, for instance, the database makes sure the money is returned to the first account by rolling back the transaction. If no problems are encountered, the transaction is committed, permanently storing the changes in the database. There's a JSTL database action to handle transactions, described in Table 11-9. Table 11-9. Attributes for JSTL <sql:transaction> Attribute name Java type Dynamic value accepted Description dataSource javax.sql.DataSource or String Yes Optional. The DataSource to use. isolation String Yes Optional. One o f read_committed, read_uncommitted, repeatable_read, or serializable. We will use it for real in Chapter 12, but let's take a quick look at how it could be used in this fictitious example: <sql:transaction> <sql:update> UPDATE Account SET Balance = Balance - 1000 WHERE AccountNumber = 1234 </sql:update> Chapter 11. Accessing a Database 178 <sql:update> UPDATE Account SET Balance = Balance + 1000 WHERE AccountNumber = 5678 </sql:update> </sql:transaction> All SQL actions that make up a transaction are placed in the body of a <sql:transaction> action element. This action tells the nested elements which database to use, so if you need to specify the database with the dataSource attribute, you must specify it for the <sql:transaction> action. The isolation attribute can specify special transaction features. When the DataSource is made available to the application through JNDI or by another application component, it's typically already configured with an appropriate isolation level. This attribute is therefore rarely used. The details of the different isolation levels are beyond the scope of this book. If you believe you need to specify this value, you can read up on the differences in the JDBC API documents or in the documentation for your database. You should also be aware that some databases and JDBC drivers don't support all transaction isolation levels. The <sql:transaction> action gets a connection from the data source and makes it available to all database actions within its body. If one action fails, the transaction is rolled back; otherwise the transaction is committed at the end of the <sql:transaction> body. 11.4 Application-Specific Database Actions You can use the JSTL database actions described in this chapter to develop many types of interesting web applications, such as product catalog interfaces, employee directories, or online billboards, without being a Java programmer. These types of applications account for a high percentage of the web applications developed today. But at some level of complexity, putting SQL statements directly in the web pages can become a maintenance problem. The SQL statements represent business logic, and for more complex applications, business logic is better developed as separate Java classes. For a complex application, it may be better to use application-specific custom actions instead of the JSTL database actions described in this chapter. For example, all the generic database actions in Example 11-1, to SELECT and then INSERT or UPDATE the database, can be replaced with one application-specific action like this: <myLib:saveEmployeeInfo dataSource="${example}" /> Part III, especially Chapter 23, describes how you can develop this type of custom action. Besides making it easier for the page author to deal with, the beauty of using an application- specific custom action is that it lets you evolve the application behind the scene. Initially, this action can be implemented so it uses JDBC to access the database directly, similar to how the JSTL actions work. But at some point it may make sense to migrate the application to an Enterprise JavaBeans architecture, perhaps to support other types of clients than web browsers. The action can then be modified to interact with an Enterprise JavaBeans component instead of accessing the database directly. From the JSP page author's point of view, it doesn't matter; the custom action is still used exactly the same way. . 11-9. Attributes for JSTL <sql:transaction> Attribute name Java type Dynamic value accepted Description dataSource javax.sql.DataSource or String Yes Optional. The DataSource to. in the web pages can become a maintenance problem. The SQL statements represent business logic, and for more complex applications, business logic is better developed as separate Java classes application to an Enterprise JavaBeans architecture, perhaps to support other types of clients than web browsers. The action can then be modified to interact with an Enterprise JavaBeans component