> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dominik
> Baranowski
> Sent: Thursday, August 02, 2001 11:32 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-user] transactions and isModified method
>
>
> thanks, Bill
>
> a few more questions in-line...
>
> >
> > problem:
> >
> > I've got rather long transactions (they begin in a session
> > bean) whithin
> > which I access other session beans and eventually CMP entity
> beans(mostly
> > getter methods). I'm getting a lot of deadlock. I'm implementing the
> > isModified() method in hopes that it will alleviate some of this
> > problem by
> > cutting down on calls to the ejbStore method.
> >
> > questions:
> >
> > 1. I'm assuming that if the ejbStore method does not get
> > called then the
> > ejbLoad method will not get called either and the cached values will be
> > used. is this right?
> >
>
> ejbLoad get's called at most once per transaction, depending on
> your commit
> option
>
> Commit option A:
> ejbLoad get's called when bean enters cache
>
> Commit option B and C:
> ejbLoad get's called once per transaction
>
> ejbStore is a different story. It is called at transaction
> commit. It can
> also be called within a transaction when a finder method is invoked. If a
> finder method is invoked within a transaction, it will call ejbStore on
> every bean of that finder's type that are involved within the transaction.
> The EJB spec requires this.
>
> even with the isModified returning false?
>
No DB update will be called if isModified returns false.
> > 2. I'm already using tuned updates but the isModified()
> > method should
> > improve things further, right? or at least overide the tuned updates
> > behavior.
> >
>
> It will improve things, but not much.
>
> > 3. is there anything else I can do to avoid deadlock? I've
> > been thinking of
> > implementing a stateless session bean facade to the entity beans.
> > Will that
> > help me to avoid deadlock?
> >
>
> I'm assuming you're getting application deadlock? That is, the order in
> which you are accessing your beans is causing your deadlock, correct? Are
> you getting SQL exceptions stating that deadlock was detected?
> Or is JBoss
> throw transaction timeouts? If the latter, then you need to
> write your app
> so it accesses beans always within a specific order
>
> yes I'm getting a timeout at the app level. everything works fine with a
> single thread, no deadlock
> but as soon as I introduce two threads then deadlock happens
> everywhere. the
> thing is that all of the methods are get( readonly)
> so why would I deadlock. why can't I just get my value from the
> entity bean
> and move on?
>
JBoss uses pessimistic locking. Whenever ANY method of an entity is called
within a transaction, that entity is locked into that transaction and no
other transaction can access that entity until the transaction commits or
rollsback. In 3.0, JBoss locking is pluggable, but only pessimistic locking
is available. Hopefully, soon, more options will be available.
You have to be very careful how you order your entity access within a
transaction.
> or maybe it's the finders that are making all the fuss...
>
No. It's your code. A finder call does not lock a bean into a transaction,
only calling a method on the entity locks it into the transaction.
Bill
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
