>Your case would be simple if it were read only. However, it's not
and that makes it complex. This isn't unique to EJB or solved
magically by EJB or any other
>technology (with the possible exception of some AI driven design
tool). This is basic concurrency and a classic case of deadlock as
explained in any introductory text
>on database design.
If this is a complex case, I am really interested in seeing a simple
case. Two views - one shows cd and related artist and the other shows
artist and related cd's. How is this complex? And this _is_ unique to
EJB. There would not be any updates to the database unless EJBs were
used. Using EJBs is the cause why ejbStore() gets called at the end
of transaction even when no updates have been made.
>As I said above, EJBs don't remove the worry of transactions. They
offer declarative transactions. That may not seem like much with a
single database in an non
>clustered server. Add multiple data sources and clustering and it's
quite a lot of complexity hidden behind the bean interface.
You were not talking about declarative transactions, but demarcating
transactions manually with JTA. You don't need EJB's for that. If you
end up writing transactions yourselfs with JTA, why use EJB's with
the added complexity when you could just use JTA separately.
Clustering? That is not part of EJB specification.
>>>Programming is all about trade offs. Following patterns blindly is
never
>>>a good idea.
>>I agree. What was the part where I was following patterns blindly?
>By assuming that a session facade with one overall transaction was
the only useful pattern.
Oh come on. How is the example I mentioned not suitable for session
facade pattern? If that is not, then what is? Have you suggested a
better alternative? Or do you just like preaching?
===========================================================================
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".
