On Fri, Oct 31, 2008 at 5:19 PM, Andrew K Gatford <[EMAIL PROTECTED]>wrote:
> The Sandesha2 layer was gradually changed to support this structure. It > was always then left to the storage managers to ensure that the beans were > sufficiently locked when returned to the sandesha2 code. yes, this is what I was doing as well. But what I found was that still there are a lot of such paths, when tested with the method Thomas has suggested. Then there is a problem of that whether these are significant in real practical usage. thanks, Amila. > > I think one of the last times that I've had to fix a dead lock was > probably in July last year -> > > Revision: 557671 > Author: gatfora > Date: 16:12:20, 19 July 2007 > Message: > Fix deadlock when piggybacking Acks where the SenderBean and RmdBean locks > are taken in the wrong order > ---- > Modified : > > /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/util/AcknowledgementManager.java > Modified : > > /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/workers/SenderWorker.java > > I might have fixed some later than this that might have been fixed under > another change. > > Andrew Gatford > Technical Project Lead > Websphere ESB Foundation Technologies > Hursley MP211 > IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN > Telephone : > Internal (7) 245743 > External 01962 815743 > Internet : [EMAIL PROTECTED] > > > > From: > "Amila Suriarachchi" <[EMAIL PROTECTED]> > To: > Andrew K Gatford/UK/[EMAIL PROTECTED] > Cc: > "[email protected]" <[email protected]> > Date: > 31/10/2008 05:57 > Subject: > Re: Sandesha2 synchronization and dead lock handling. > > > > > > On Fri, Oct 24, 2008 at 3:31 PM, Andrew K Gatford <[EMAIL PROTECTED]> > wrote: > I went through similar pain when implementing a StorageManager and > encountered a number of deadlocks similar to the ones that you describe. > What I have gradually done is eliminate these in both the InMemory store > and my store by changing the ordering the beans were taken in. > > In general the beans are taken in this order. > > RMSBean or RMDBean followed by > SenderBean or InvokerBean. > > Did you do this at the storage level or at Sandesha2 level. Could you > please suggest the way to implement this > with the current jdbc persistence storage? > > thanks, > Amila. > > > In cases where both the RMSBean and RMDBean are locked, they tend to be > taken in that order - RMS followed by RMD. > The one thing that I do know is that it is fairly easy to introduce new > deadlocks by slightly altering the order that beans are read. > > The one question I have is how does the jdbc store handle multiple threads > accessing multiple sequences, or even a single sequence, but with multiple > threads sending multiple requests. From my experience this is where we > have found a lot of problems in the InMemory store and I expect to be even > more painful with a jdbc store. > > Andrew Gatford > Technical Project Lead > Websphere ESB Foundation Technologies > Hursley MP211 > IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN > Telephone : > Internal (7) 245743 > External 01962 815743 > Internet : [EMAIL PROTECTED] > > > > From: > "Amila Suriarachchi" <[EMAIL PROTECTED]> > To: > "[email protected]" <[email protected]> > Date: > 24/10/2008 10:30 > Subject: > Sandesha2 synchronization and dead lock handling. > > > > hi all, > > This is regarding the issue [1]. > > First of all as I learned Sandesha2 uses different beans to keep the state > of the sequence and the messages. In a dual channel mode > different threads can access these beans and update them concurrently. So > the synchronization of these beans done by using the > storage level transactions. Therefore Sandesha2 needs an storage which > supports isolated transactions. > > To synchronize these beans the transactions must be completely isolated. > i.e It should not allow simultaneous reads of > same record from different transactions. Therefore I think the problem I > saw on[1] because not isolating the transactions properly. > > Then I increased the transaction isolation to fix the above problem. It > fixed that problem but results in dead locks. > The reason I believe for this dead locks is that different transactions > try to access the data base tables in different order. > But unfortunately I could not fix the issue. > > Normally these types of dead locks are prevented by accessing resources in > same order. Does Sandesha2 follows such a order or any > other technique? > > Or is there any other reason for this dead locks and synchronization > problems? Can someone > have a better idea of Sandesha2 Design shed some light on this? > > thanks, > Amila. > > > [1] http://issues.apache.org/jira/browse/SANDESHA2-179 > -- > Amila Suriarachchi > WSO2 Inc. > blog: http://amilachinthaka.blogspot.com/ > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > > > -- > Amila Suriarachchi > WSO2 Inc. > blog: http://amilachinthaka.blogspot.com/ > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
