Part II. Java Persistence and Java SQL Data Access

In Part I, we covered in depth Java in the database, including the rationale for using Java in the database, an overview of the Oracle implementation, and the various application types enabled by an embedded Java virtual machine in the database. However, database programming using Java goes way beyond running Java in the database; in fact, the largest part of database programming using Java happens in the middle tier (i.e., J2EE, J2SE, object to relational mapping iconified by Toplink, and database-related Java design patterns).[1]

The relational database (RDBMS) world and the Java world do not share the same model or semantics. On one hand, we have the relational technology, which includes the SQL language, the RDBMS semantics (i.e., schemas, tables, primary keys, foreign keys, views, stored procedures), and a set of proprietary and open languages for building stored procedures, functions, and packages on top of SQL. On the other hand, we have the Java technology and platform, which includes the object-oriented Java language, the design patterns, a rich set of JCP-sanctioned APIs and enterprise services, and a growing number of open source frameworks and programming models. The mapping between database semantics (SQL data) and Java semantics (i.e., Java state) is achieved through numerous Java APIs, design patterns, and frameworks.

We can group these into two categories:

  1. The do-it-yourself persistence technologies and APIs, such as JDBC, SQLJ, and vendor-specific tools/utilities such as Oracle JPublisher. These technologies explicitly manipulate SQL statements, stored procedures to access or persist Java states into relational tables columns, under the control of the application developer.

  2. The transparent persistence (O/R mapping) technologies, which include frameworks such as Toplink, JavaBeans, JDO, Enterprise JavaBeans, POJOs, and so on. These technologies shield the Java developer from the hassle of doing it by transparently mapping Java objects states to database tables/columns. Ultimately, these technologies use JDBC or SQLJ or stored procedures under the covers.

In Part II, we’ll focus on the do-it-yourself Java API for accessing SQL data and persisting Java states in the Oracle database, including JDBC and Oracle’s implementation, SQLJ and Oracle’s implementation, and Oracle’s JPublisher (which complements JDBC and SQLJ for dealing with advanced/complex Oracle Database types but also enables Database Web Services, covered in Part III).

Database Programming with Oracle JDBC

Enterprise computing is not conceivable without RDBMS access. It’s no surprise then that the JDBC API remains by far the most-used Java API either directly or under the covers. Part II will give you a condensed but hopefully comprehensive and pragmatic coverage of Oracle JDBC. We first introduce the JDBC technology, review the various JDBC specifications, and then look at the implementation of Oracle JDBC, including its architecture, packaging, the level of support for standard APIs, the Oracle extensions, transaction handling, security handling, manageability, and advanced JDBC connection pooling mechanisms for scalability, load balancing, fail-over, and troubleshooting. Most of the features described apply to the server-side JDBC, which is used by Java in the database.



[1] There is no enterprise/transactional Java application without RDBMS data access.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.137.7