user manual

152 BES Developer’s Guide
Container-Managed Persistence in Borland Enterprise Server
You can declare an entity bean reentrant in the deployment descriptor;
however, take special care in this case. The critical issue is that a Container
can generally not distinguish between a (loopback) call within the same
transaction and a concurrent invocation (in the same transaction context) on
that same entity bean.
When the entity bean is marked reentrant, it is illegal to allow a concurrent
invocation within the same transaction context on the bean instance. It is the
programmer's responsibility to ensure this rule.
Container-Managed Persistence in Borland Enterprise Server
The Borland Enterprise Server's EJB Container is fully J2EE 1.3 compliant. It
implements both container-managed persistence (CMP) for Enterprise
JavaBeans implementing either the EJB 1.1 and/or EJB 2.0 specifications.
The bean provider designs persistence schemas for their entity beans,
determines the methods for accessing container-managed fields and
relationships, and defines these in beans' deployment descriptors. The
deployer maps this persistence schema to the database and creates any other
necessary classes for the beans' maintenance.
The EJB 2.0 Specification from Sun Microsystems details the specifics for the
bean and container contracts in Chapters 10 and 11. Creating the persistence
schema is not in the scope of this document, but is well discussed in both the
Sun specification and in the Borland JBuilder documentation, the relevant
parts of which are the Enterprise JavaBeans Developer's Guide and the
Distributed Application Developer's Guide.
About the Persistence Manager
The Persistence Manager (PM) provides a data-access layer for reading and
writing entity beans. It also provides navigation and maintenance support for
relationships between entities and extensions to EJB-QL. Currently, the PM
only supports data access to relational database by means of JDBC. The PM
uses an optimistic concurrency approach to data access. Conflicts in resource
state are resolved before transaction commit or rollback by use of verified SQL
update and delete statements.
Although the PM does not manage transactions (this is the Container's
responsibility), it is aware of transaction start and completion and can
therefore manage entity state. The PM uses the TxContext class to represent
the root of managed entities during transaction lifecycles. When the container
manages a transaction it asks the PM for the associated TxContext instance. If
none exists, as is the case when a new transaction has started, one is created
by the PM. When a transaction is completing, the container calls the method
TxContext.beforeCompletion() to alert the PM to verify entity state.
The PM has complete responsibility for entity data storage and the
maintenance of the state of relationships between entities. Relationship