In the pessimistic locking mode that Mr. Arkin discusses below, when the
bean goes into update mode, will some sort of cloning mechanism be needed so
that the in-flight changes made to the single entity bean instance are not
seen by read-only requests? Also, if transactions are managed by the
container, either all of the setters / modifiers on the entity bean would
need to be "wrapped" in some sort of session bean method for which the
transaction would be active. Otherwise, every setter on the entity bean
would have to start and end a separate transaction unless the setters were
declared as TX_NOT_SUPPORTED or something like that. Do I have this right?
My project would like to have form handlers calling setters on entity beans
directly, but unless client-controlled transactions are used, it seems that
session beans would be needed to handle the scope of the transaction. But
if session beans are used to interact with the entity beans, then some sort
of data object is needed to gather up the changes from the form before
sending the data to the entity bean (through the session bean). If this is
true, then the data object starts to look a lot like the entity bean with
duplicate attributes and maybe duplicate validation / processing logic.
Then entity beans don't really buy us a lot for updates. Entity beans are
still nice for read-only use, but only if the entity beans are kept in an
active pool for a while, or the state of the bean is always kept nearby in
the write-through data cache that you speak of. Again, do I have this
right?
Thanks,
DB
-----Original Message-----
From: Assaf Arkin [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 24, 2000 1:11 PM
To: [EMAIL PROTECTED]
Subject: Re: Caching of read-only DB contents in an EJB
"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".
===========================================================================
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".
