Actually, it looks like the best approach is to change the transaction
attribute of my search session bean.
Deadlock does not occur if I use the "NotSupported" transaction
attribute. (Originally I used "Required" -- but transactions are not
needed for read-only search, and in fact cause the deadlock.)
-----Original Message-----
From: Keith L. Musser <[EMAIL PROTECTED]>
To: jBoss <[EMAIL PROTECTED]>
Cc: Nortje, Andrew <[EMAIL PROTECTED]>; Rickard �berg <[EMAIL PROTECTED]>
Date: Thursday, November 30, 2000 1:08 PM
Subject: Re: [jBoss-User] deadlock accessing EntityBeans
>I don't like any of the options...
>
>(1) transaction timeout - bad performance; may force client to retry,
>etc.
>(2) reorganize logic to guarantee sequence -- not really feasible with
>sophisticated recursive search algorithm.
>(3) make entities re-entrant -- that's suitable for some methods but
not
>others on my entity.
>(4) in "search" session bean, synchronize on a static mutex object to
>serialize access to search bean -- easy fix, but not very scalable and
>not sanctioned by EJB.
>
>But I understand and I'll pick the least-terrible method.
>
>Will the optimistic cache be the default in the future?
>
>- Keith
>
>-----Original Message-----
>From: Nortje, Andrew <[EMAIL PROTECTED]>
>To: 'jBoss' <[EMAIL PROTECTED]>
>Date: Thursday, November 30, 2000 12:43 PM
>Subject: RE: [jBoss-User] deadlock accessing EntityBeans
>
>
>>Keith
>>
>>You can define your entity beans to be reentrant in ejb-jar.xml like
>this.
>>This might fix your problem. The J2EE spec discourages this, can't
>remember
>>the exact reasons right now...
>>
>> <entity>
>> <description>Member Bean</description>
>> <display-name>Member Bean</display-name>
>> <ejb-name>Member</ejb-name>
>> <home>com.uni.entity.myaccount.MemberHome</home>
>> <remote>com.uni.entity.myaccount.Member</remote>
>> <ejb-class>com.uni.entity.myaccount.MemberBean</ejb-class>
>> <persistence-type>Bean</persistence-type>
>> <prim-key-class>com.uni.entity.myaccount.MemberPK</prim-key-class>
>> <reentrant>True</reentrant>
>> <resource-ref>
>> <res-ref-name>jdbc/UniteItDB</res-ref-name>
>> <res-type>javax.sql.DataSource</res-type>
>> <res-auth>Container</res-auth>
>> </resource-ref>
>> </entity>
>>
>>
>>
>>> -----Original Message-----
>>> From: Rickard Oberg [mailto:[EMAIL PROTECTED]]
>>> Sent: Thursday, November 30, 2000 12:24 PM
>>> To: jBoss
>>> Subject: Re: [jBoss-User] deadlock accessing EntityBeans
>>>
>>>
>>> Hi!
>>>
>>> "Keith L. Musser" wrote:
>>> > I have a SessionBean which performs a search on Entity Beans. The
>>> > sequence in which the search accesses the Entity Beans
>>> depends on call
>>> > arguments to the session bean.
>>> >
>>> > When I invoke the session bean from multiple clients, I get
>>> deadlock.
>>> >
>>> > This appears to be because search 1 assesses entity A
>>> first, then entity
>>> > B. Search 2, however, acesses entity B first, then entity A.
>>> >
>>> > So if the timing is just wrong, both searches get the first
>>> entity, but
>>> > cannot get the second, since it's locked by the other search.
>>> >
>>> > Is there a way to set up jboss.xml to prevent this from happening?
>>>
>>> This is a known issue with concurrent systems and pessimistic
>>> concurrency schemes (which is what our cache uses). You should
either
>>> wait for transaction timeout and retry, or make sure that they are
>>> always used in the same order.
>>>
>>> There are plans to make an optimistic concurrency cache which
>>> would fix
>>> this, but this will not be done for awhile.
>>>
>>> regards,
>>> Rickar
>>>
>>> --
>>> Rickard Oberg
>>>
>>> Email: [EMAIL PROTECTED]
>>>
>>>
>>> --
>>> --------------------------------------------------------------
>>> To subscribe: [EMAIL PROTECTED]
>>> To unsubscribe: [EMAIL PROTECTED]
>>> Problems?: [EMAIL PROTECTED]
>>>
>>
>>
>>--
>>--------------------------------------------------------------
>>To subscribe: [EMAIL PROTECTED]
>>To unsubscribe: [EMAIL PROTECTED]
>>Problems?: [EMAIL PROTECTED]
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
