Summary

Today, you've seen that EJB containers support container-managed transaction demarcation, but that your Session beans can take control using bean-managed transaction demarcation, if needed. Behind the scenes, there are some complex goings on with the XA interfaces to support distributed transactions, using 2PC and XA-aware data store connections, such as javax.sql.XADataSource.

JDBC is the de-facto way for implementing persistence of Java objects, and JDBC 3.0 unifies the various classes and interfaces in the java.sql and javax.sql packages. JDBC 2.1 and 3.0 have fleshed out support for the most relevant features of SQL1999, specifically abstract data types.

The SQLj initiative addresses both client-side integration of SQL and Java (part 0) and server-side (that is, database) integration (parts 1 and 2). SQLj part 0 is more succinct than JDBC, but is not particularly well tailored to the J2EE environment, because for the most part, it pre-dates it. SQLj parts 1 and 2 offer some opportunities to radically change the way that databases are used, with SQLj part 2 operating in much the same space as the SQL1999 abstract data types.

JDO is a new specification that aims to make Java persistence totally transparent. It is a natural fit for OODBMS and O/R mapping tool vendors and also works as a front-end to ERP systems. JDO primarily focuses on the API into the client-side cache of persistent objects, leaving much of the back-end configuration to the JDO implementation vendors.