Information Technology Reference
In-Depth Information
agent.remove();
// or: agentHome.remove(uuid);
S
AMPLE
13. Deleting an Agent.
4 . 3
C o m p a r i s o n o f S D O a n d E J B A p p l i c a t i o n P r o g r a m m i n g
M o d e l s
The SDO architecture uses a
two-level
store approach to database-state manage-
ment. That is, an explicit distinction is made between the DataObject(s) that are
resident in memory (the first-level store) and the persistent data resident in the data-
base (the second-level)
[24]
. Operations must be explicitly invoked on the DAS in
order to copy state between the two levels.
With respect to entity beans, in contrast to the two-level store approach used by
SDOs, EJBs use a
single-level
store approach
[5]
. That is, no distinction is made
between the instantiated (in-memory) (entity bean) component and the persistent
copy. Essentially, whenever the in-memory component is modified, the persistent
copy is automatically updated (although the changes are not committed until the
transaction is committed). This has a number of advantages over two-level store: first,
since a maximum of one copy of each component is memory-resident, the application
does not have to worry about aliasing problems, in which the application accidentally
obtains multiple copies of the component, and their states become different. Second,
the application does not have to remember to propagate updates from the in-memory
copy to the persistent copy. This is handled automatically at commit time.
In order to implement single-level store, each component must be assigned a
unique identity. This allows the middleware to maintain an association with its loca-
tion in persistent storage. In addition, it allows the middleware to detect references
to components already in memory, and thus avoid duplicate copies (aliasing). For
EJBs, the EJB container is responsible for maintaining the mapping between a com-
ponent and its persistent state, obviating the need for explicit state-transfer methods.
The mapping consists of two parts: the abstract persistence schema and the com-
ponent identity definition. The abstract persistence schema specifies the mapping
between portions of the database record and the bean's corresponding
getter
and
setter
methods. The component identity definition defines the subset of the data-
base record used to uniquely identify the component: this is always “read-only” state,
since changing this state causes the object's identity to change as well.
For an example of the potential problems of aliasing, suppose that the application
retrieves a data graph DG1 from the DAS, and then retrieves a second data graph
DG2 from the DAS. DataObjects in DG1 and DG2 which represent the same logical
