Joe,
An old CS professor of mine took great delight in reminding us that if you
use shared resources with locks you had to develop a shared order for
obtaining and locking the shared resources. If you didn't, the system would
contain deadlock potential and be virtually impossible to debug with
multiple users.
Forget mapping every scenario permutation and instead establish a standard
sequence for obtaining locks/semaphores or whatever you use to arbitrate
access to your shared resources. Then train your team on the policy and
enforce it. You may have granularity problems to refine, but stuff will work
deterministically in the mean time. Which is usually a fair trade in this
business.
Best,
Dwight
-----Original Message-----
From: Herbers, Joe [SMTP:[EMAIL PROTECTED]]
Sent: Monday, July 24, 2000 1:08 PM
To: [EMAIL PROTECTED]
Subject: Re: EBs are slow (was Clustering)
Thanks for this and other responses to my post. Yes, transactions
will
improve performance over EBs. I didn't mention that initially we
used tx
across all our SBs and EBs. However, this brought up a different
problem:
deadlock! You have to be careful of situations such as SB1 touching
EB1 and
EB2 while SB2 touches EB2 then EB1 - this can result in deadlock and
did for
us. Trying to untangle all possible scenarios of this is daunting
so the
first solution is to shut of tx.
But probably the thing to do now is go back and try to add them in
carefully. But the possibility for deadlock looms since no one
person (at
least not on a large project) can know all the SBs that will access
various
EBs and the order they will do it in. When asked about this, one
WebLogic
consultant's response was "all the systems I've seen have used only
Stateless SBs with JDBC", hence my concern. Guidnace on this is
welcome.
On Mon, 24 Jul 2000 10:22:25 -0700, Gene Chuang <[EMAIL PROTECTED]>
wrote:
>> We've seen that if people coded a sess bean to create a new EB
and
>> then call all the setters to define the content that the
performance
>> is terrible because the EB hits the DB for each setter.
>
>Not if you set the appropriate transactions! For example, if your
Session
>bean is REQUIRES_NEW and your Entity bean is REQUIRED, then the db
will be
>updated just once: at the end of the txn! And on the same note,
ejbLoad
>will only be called once, at the beginning of the txn... Hence the
wise
>usage of transaction management will give you wonderful performance
gains!
===========================================================================
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".
