web server - Borland Technical Publications

Container-Managed Persistence in Borland Enterprise Server
UpdateModifiedFields
VerifyModifiedFields
Note
This option is the default optimistic concurrency behavior. The container issues an
update only on the fields that were modified in the transaction, or suppresses the
update altogether if the bean was not modified. Consider the same bean from the
previous example, and assume that only VALUE1 was modified in the transaction.
Using UpdateModifiedFields, the container would issue the following update:
UPDATE MyTable SET (VALUE1 = value1) WHERE KEY = key
This option can provide a significant performance boost to your application. Very often
data access is read-only. In such cases, not sending an update to the database upon
every transaction saves quite a bit of processing time. Suppressing these updates also
prevents your database implementation from logging them, also enhancing
performance. The JDBC driver is also taxed far less, especially in large-scale EJB
applications. Even for well-tuned drivers, the less work they have to perform, the better.
This option, when enabled, orders the CMP engine to issue a tuned update while
verifying that the updated fields are consistent with their previous values. If the value
has changed in between the time the transaction originally read it and the time the
transaction is ready to update, the transaction will roll back. (You will need to handle
these rollbacks appropriately.) Otherwise, the transaction commits. Again using the
same table, the CMP engine generates the following SQL using the
VerifyModifiedFields behavior if only VALUE1 was updated:
UPDATE MyTable SET (VALUE1 = value1) WHERE KEY = key AND VALUE1 = old-VALUE1
VerifyAllFields
This option is very similar to VerifyModifiedFields, except that all fields are verified.
Again using the same table, the CMP engine generates the following SQL using this
option:
UPDATE MyTable SET (VALUE1 = value1) WHERE KEY = key AND VALUE1 = old-VALUE1
AND VALUE2 = old-VALUE2
The two verify settings can be used to replicate the SERIALIZABLE isolation level in the
Container. Often your applications require serializable isolation semantics. However,
asking the database to implement this can have a significant performance impact.
Using the verify settings allows the CMP engine to implement optimistic concurrency
using field-level locking. The smaller the granularity of the locking, the better the
concurrency.
Persistence Schema
The Borland CMP 2.0 engine can create the underlying database schema based on
the structure of your entity beans and the information provided in the entity bean
deployment descriptors. You don't need to provide any CMP mapping information in
such cases. Simply follow the instructions for “Specifying tables and datasources,”
below. Or, the CMP engine can adapt to an existing underlying database schema.
Doing so, however, requires you to provide information to the CMP engine about your
database schema. In such cases, you should refer to the CMP mapping sections,
below, as well as CASE 2 in “Specifying tables and datasources.” See “Basic Mapping
of CMP fields to columns” on page 133.
Specifying tables and datasources
The minimum information required in ejb-borland.xml is an entity bean name and an
associated datasource. A datasource is used to obtain connections to a database.
Information on datasource configuration is given in Chapter 21, “Connecting to
Resources with BES: using the Definitions Archive (DAR).” There are two means of
providing this information.
132 BES Developer’s Guide