In the J2EE environment, you have a choice of using native file I/O, serialization, JDBC, entity beans, session beans, or JDO persistent classes as the implementation strategy for persistence of your application object model (persistent entities). In many cases, you can use more than one strategy in the same application.
File I/O and serialization based on files are not robust or scalable enough for application-server use beyond trivial storage of a simple class state, and we will not describe these options further. The choice between the other strategies depends on your requirements for the persistence abstraction.
Using JDBC or JDO directly allows your application to store
entities using a local-persistence interface with minimum security and
transaction-association options. That is, the security context of the
caller of each business method governs access to the resources, and
the transaction context of the caller is the transaction context of
all the calls made to the local-persistence interface. In our example
transaction and security checks are performed only when the container
receives an invocation on
) and calls your application code.
The local-persistence alternatives do not allow transparent execution of the implementation methods in different tiers of the architecture. All calls are local and use resource managers in the same JVM as the caller.
We have already seen how using ...