"Bechtold, Douglas" wrote:
>
> How will this eventual CMP implementation work? Would the instance of the
> entity bean itself be put in the cache, or a just an object representing the
> state of the entity bean? Either way, isn't it the container that would
> have to realize that when the entity bean is requested, that the first thing
> to do would be check the cache to see if the information is there already,
> correct? If the container can do this for CMP, what is left to overcome in
> order to support BMP as well?
An object representing the state of the bean will be cached, not the
bean itself.
In optimistic locking mode each transaction gets a copy of the object to
work against. The assumption is that the entity beans are often read,
seldom modified (concurrently).
In pessimistic locking mode only one entity bean is accessible at once
(to prevent concurrent updates), the bean is always synchronized with
the database through the cache. In this cache that cache is used for
rolling back objects to their previous state.
Dirty checks can be done based on the object contents or some stamp
(e.g. RAWID, TIMESTAMP) based on the SQL connector you choose to use.
The container can do this for CMP because the container has full control
over every bean. In BMP the container cannot guess your SQL and affect
the locks, the time stamp, etc.
You can still use this mechanism from BMP, if you want. It provides two
APIs, one for the CMP engine and one for regular applications based on
the ODMG API. So you can write a BMP on top of the CMP and exert more
control on the process.
arkin
>
> DB
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
