On Mon, 24 Jul 2000 11:40:08 -0400, James Cook <[EMAIL PROTECTED]> wrote:
>There may be more to your design than you have elaborated, but the symptoms
>that you believe you are seeing have nothing to do with the use of entity
>beans. All setters called from a single entry point in a session bean will
>execute in the same transaction, and ejbLoad will only be called one time
on
>the entity bean. If you are seeing behavior other than this, it is most
>likely a design failure, or improper use of RequiresNew on the entity
bean's
>methods.
Hmm...could you elaborate on this a bit more? If I only mark the EB as
TxReq and mark the SB as TxSup (or TxNotSup) then when the SB invokes
several EB methods in a row, will each get its own tx? If so, then this
doesn't really help, right? In other words, do I have to force a tx to be
started in the SB by marking its methods with TxReq? As mentioned in a
related response to this, I am worried about deadlock when there are various
SBs accessing overlapping sets of EBs (possibly in different orders which is
what has caused us deadlock in the past).
>We have to prepare ourselves for more "bad juju" regarding entity beans.
>They are frequently considered a bottleneck in the EJB spec, requiring more
>and more hardware to run fast. In truth, a well-designed approach to using
>entity beans can result in a very fast application. When used properly,
they
>*do* scale well. We just have to do a better job at educating people how to
>design better.
This may very well be true. Unfortunately, it sounds like which AppServer
and which DB you are using makes a difference. It appears that because we
are using Oracle with WebLogic we get different results than someone using
some other combination (the WL docs specifically mention how Oracle behaves
differently because of Optimistic vs. Pessimistic locking) The isolations
levels are especially hard to discern. So, yes, there is a lack of
understanding about how things should work in a particular configuration.
Anything you can do to better help us design a solution to this is welcome.
>DBShared (Option A in EJB spec) is typically a poor modeling choice.
>very difficult to predict what resources your application may need in the
>future.
Agreed. Thanks for your feedback on these issues.
Joe
===========================================================================
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".
