Douglas,
You said:
> -----Original Message-----
> From: Bechtold, Douglas [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 25, 2000 8:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> 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?
>
Either the container maintains instances per transaction ("clone" as you
say), or invocations are serialized through a single bean instance. The
latter approach could be a serious scalability issue IMHO.
> 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?
>
Yes. That is why you probably don't want to have transactions against you
EB's include user think time. Better to pull the state out of the component,
manipulate it outside of transaction, and apply the mutations in a short
transaction. This requires a level of "dirty checking" as we have been
discussing in this thread.
> 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.
>
I assume you are refering to using a stateful session bean to buffer the
updates outside of transaction boundaries?
> 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).
>
Yes.
> 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.
>
Right. The Entity Bean can be just a shell around the domain objects. The
Entity Bean is just providing the hooks into the container for life cycle
and transaction control.
> Then entity beans don't really buy us a lot for updates.
>
The issue of updating in a distributed environment is the same regardless of
life cycle control (which is what EB's give us). Typically you want to
buffer updates between transactions in such an environment. Whether you are
using Entity Beans or not you would find yourself playing the same games (we
did a lot of stuff like this in the raw CORBA days, and in days of wine and
roses of distributed Smalltalk).
> 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?
>
Yup, I think so.
> Thanks,
> 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".
