Discuss the following approaches to persistence:

(a) Container-Managed Persistence (CMP).
(b) Bean-Managed Persistence.
(c) JDBC.
(d) SQLJ.
(e) JDO.

(a) Container-Managed Persistence (CMP).
With CMP, persistence is provided automatically by the container. See Section 29.7.4.
(b) Bean-Managed Persistence.
With BMP, the component developer has to write the necessary code to make the bean persist,
using an API such as JDBC or SQLJ, or using Java serialization. Alternatively, an object-
relational mapping product like TopLink can be used to automate or facilitate this mapping
(see bullet points prior to start of Section 29.7.1.).
(c) JDBC.
JDBC is a low-level middleware tool that provides basic features to interface a Java
application with a relational DBMS. Using JDBC, developers need to design a relational
schema to which they will map Java objects. Subsequently, to write a Java object to the
database, they must write code to map the Java object to the corresponding rows of the
corresponding relations, as we illustrated in Section 27.4. A similar procedure is required in
the other direction to read a Java object from the database. See Section 29.7.1.
(d) SQLJ.
SQLJ is based on static embedded SQL while JDBC is based on dynamic SQL. Thus, SQLJ
facilitates static analysis for syntax checking, type checking, and schema checking, which may
help produce more reliable programs at the loss of some functionality/flexibility. It also
potentially allows the DBMS to generate an execution strategy for the query, thereby
improving the performance of the query. JDBC, based on dynamic SQL, allows a calling
program to compose SQL at runtime. See Section 29.7.2.
(e) JDO.
JDO is another Java-based persistence mechanism, derived from the ODMG Java binding.
The development of JDO had two major aims:
? To provide a standard interface between application objects and data sources, such as
relational databases, XML databases, legacy databases, and file systems.
? To provide developers with a transparent Java-centric mechanism for working with
persistent data to simplify application development. While it was appreciated that lower-
level abstractions for interacting with data sources are still useful, the aim of JDO was to
reduce the need to explicitly code such things as SQL statements and transaction
management into applications.