You're absolutely right. Most resources do not support the diamond case,
an attempt to access them from multiple servers will result in locking.
The only way around it is to make sure all beans accessed in the context
of a transaction run in a single server. Most of the time that's not a
problem.
True, load balancing should allow you to use a bean on any arbitrary
server in a cluster, but if you look at the cost of even doing
distributed transactions, limiting a transaction to a single server does
not cost you much. You can still have transactions load balace to
different servers each time you begin a new transaction.
arkin
Bert Robben wrote:
>
> Hi all,
>
> I have a question regarding the diamond case mentioned in the ejb spec 1.1
> (see chapter on transactions).
>
> Is it possible that I can even get such a case if I make 2 calls to the
> *same* enterprise bean inside a single transaction ?
>
> For instance:
>
> class BeanX implements SessionBean {
> ...
> void operation() throws RemoteException {
> someOtherBean = ... ; get ref through some home interface
> someOtherBean.call();
> ...
> someOtherBean = ... ; get same ref through same home
> interface someOtherBean.call();
> }
> ...
> }
>
> If I would execute this operation in a single transaction on a clustered app
> server (i.e. one that supports loadbalancing), it is not sure that the call
> would get executed on the same server machine. If this would be the case,
> then I think you have the diamond case, meaning that you need distributed
> transactions (which is not supported by most resources).
>
> If this is true, then this means that I always have to design my entity
> beans very very carefully in such a way that the interaction patterns are
> very simple and such cases can not happen. In the example, this might seem
> simple, but it can become much harder when I add indirections, for instance
> when beanX would call BeanY and BeanY would call someOtherBean for the
> second time.
>
> please correct me where I am wrong,
>
> Bert
>
> ===========================================================================
> 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".
