Isolation Requirement Info:
The SPECjAppServer entity beans were deployed using the following logical
isolation levels (using the EAServer 'cmp_iso_level' configuration property).
In all cases, if a transaction is rolled back due to deadlock
(when using pessimistic locking), or rolled back due to changes
that are detected by the optimistic concurrency control mechanisms,
the transaction is automatically retried.
Some entities used Commit Option B, some used Commit Option C.
In all cases, ejbLoad is called on each entity instance before it is
used in any transaction. In some cases, ejbLoad may obtain data from
an in-memory cache instead of the DBMS, as explained in detail below.
repeatable_read, using selectWithLock (shared lock at select time)
Using Sybase ASE "select ... holdlock".
Mfg: WorkOrderEnt
Supplier: SComponentEnt
repeatable_read, using selectForUpdate (exclusive lock at select time)
Using "no-change-update before select" - Sybase ASE does not support
select ... for update" directly.
Util: SequenceEnt
Mfg: InventoryEnt
repeatable_read, using row-level timestamp
Each table has an additional 'ts' (database-level timestamp) property
which is loaded at select time. When the entity is updated, deleted
or verified (at commit time if unchanged by the transaction), the
current timestamp value in the DBMS is checked against the original
loaded timestamp. If there is a mismatch (or if the row has already
been deleted), the transaction is rolled back.
Order: OrderEnt, OrderLineEnt
Supplier: POEnt, POLineEnt
read_committed, with no locks, no commit-time verification
Mfg: LargeOrderEnt
read_committed_with_cache, using row-level timestamp
Like read_commited, using row-level timestamp. However, the row
data may sometimes be loaded from an in-memory cache in the application
server instead of a SQL select. The update, delete or commit-time verify
steps all ensure that the transaction is rolled back if it used stale
cache data.
Corp: CustomerEnt
Orders: OrderCustomerEnt
repeatable_read_with_cache, using table-level timestamp and query cache with verify
ejbLoad and finder methods are satisfied from in-memory cache (if possible).
A separate timestamp table (ref_ts) contains a single timestamp value
that is updated any time there is an insert, delete or update on any
of the referenced tables. The timestamp is updated using database triggers,
which are automatically created by the CMP runtime. A commit-time verify
step ensures that no changes (insert, delete or update) have occurred to
any of the referenced tables during the transaction. If any changes occur
in any of the referenced tables, the transaction is rolled back.
Corp: DiscountEnt, RuleEnt
Mfg: AssemblyEnt, BomEnt, ComponentEnt, PartEnt
Orders: ItemEnt
Supplier: SupplierEnt, SupplierCompEnt
|
