Re: How to avoid database deadlocks?

Hi Janne!

What is your rational for using BMT, You rarely see BMT being used
those days. BMT, as you and others of this thread has pointed out, adds
its own set of mechanics you will need to fight (at least in the case
of searching for data).

/Johan

2003-11-24 kl. 15.00 skrev Janne Mattila:

>> 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".
>

===========================================================================
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".