"Bechtold, Douglas" wrote:
>
> 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
No need to in pessimistic, only one transaction is allowed to touch the
bean. But you do get the cloning mechanism, so the bean's values can be
reverted to their original state should the transaction rollback.
In optimistic mode two transactions can interact with the same bean, so
you get two clones.
> 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?
Start a transaction, set property X, set property Y, set property X
again, commit the transaction -- update occurs only once at the very
end. In fact, the update occurs when the full transaction completes, and
is dependent on whether the other updates in the transaction succeeded.
For example, if you update bean A and bean B, and there's a problem in
persisting bean B (say, duplicate primary key), then both A and B will
be rolled back.
> 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
Yes, you must define a transaction boundary that spans more than a
single method call, otherwise you get a transaction per set method. It's
not what you expect, but it's very useful in some other implementation.
You can also perform the set methods outside a transaction, but then you
can get into potential conflicts (like concurrent updates). Transaction
integrity is only assured while you are inside a transaction (even if
it's through soft locking).
> 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.
That has always been a problem and I don't find entity beans to be a
solution.
I believe that all good solutions are simple solutions. A solution that
involves collecting the changes in the UI (could take a few minutes, an
hour, or never finish) and then performing them against an entity bean
is a simple one for all partied involved (back-end).
It works with JDBC, it works with CMP, it works with MTS, it works with
XML messaging, it works with JMS, etc.
A solution that allows you to somehow update the bean while not in a
transaction, yet assure that only you transaction (how?) is touching it,
and in the end actually get the updates to occur without concurrency
issues can be done (and has been done), but it's very server dependent.
Will work with CMP but not with JDBC, will work with one EJB server but
not another, will not work with XML messaging or JMS, etc.
> 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?
I think entity beans only work well if you could say the following:
1. Write a Java object to represent an SQL object
2. Get it working without breaking anything, escalating locks, losing
transactional integrity, etc.
3. Lose you Java object, use an entity bean instead
Whatever you cannot do in 2, you cannot easily, reliabily and portably
do in 3.
arkin
>
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
