Return-Path: Delivered-To: apmail-ws-sandesha-dev-archive@www.apache.org Received: (qmail 34955 invoked from network); 24 Oct 2008 13:04:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Oct 2008 13:04:18 -0000 Received: (qmail 62010 invoked by uid 500); 24 Oct 2008 13:04:20 -0000 Delivered-To: apmail-ws-sandesha-dev-archive@ws.apache.org Received: (qmail 61940 invoked by uid 500); 24 Oct 2008 13:04:20 -0000 Mailing-List: contact sandesha-dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list sandesha-dev@ws.apache.org Received: (qmail 61929 invoked by uid 99); 24 Oct 2008 13:04:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Oct 2008 06:04:20 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of amilasuriarachchi@gmail.com designates 66.249.92.169 as permitted sender) Received: from [66.249.92.169] (HELO ug-out-1314.google.com) (66.249.92.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Oct 2008 13:03:10 +0000 Received: by ug-out-1314.google.com with SMTP id j30so188717ugc.22 for ; Fri, 24 Oct 2008 06:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=xrFrDPY+jfuaauieYFENBGHegYMWaYUH3D7La1XaHrs=; b=veGD/lyw3Kvl6pXU4COK2LUDWwx89WLjbZ4LDrZGaJMevqZoydMqzr4QNJWOWDAmtb Njgn9tXBhQon98sbcaMtXwz2rJZ4NcXmSkq6GgxcbfF++tFeqjfV1Nhu7HBkc46g5fRO 6Z7eMt05H0IvsEPM8kySLyY35FSk922OyAcCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=sBF/5mZvji46t32mjUlz/SR31Unm8XXWikE1ZRA75Mr1JuvmEBuhRs7PZL5YHTBWoo te0W/TXF2L2eeZK4c/Gc/whMwa+Zk6IOLhAeIwFdTh6JadYIVNDcGtG3gNxvkjBeiiQ/ ngLc/5Zt5BRi/CejzfYOrNMBMkP+D7RZ7eTJ8= Received: by 10.103.227.10 with SMTP id e10mr1019211mur.38.1224853417172; Fri, 24 Oct 2008 06:03:37 -0700 (PDT) Received: by 10.103.18.20 with HTTP; Fri, 24 Oct 2008 06:03:37 -0700 (PDT) Message-ID: <60708f4b0810240603p1314d9a7g631a52fbe1f4e80c@mail.gmail.com> Date: Fri, 24 Oct 2008 18:33:37 +0530 From: "Amila Suriarachchi" To: "Thomas McKiernan" Subject: Re: Sandesha2 synchronization and dead lock handling. Cc: "Andrew K Gatford" , "sandesha-dev@ws.apache.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49283_22244395.1224853417175" References: <60708f4b0810240226l6e25d96boccf15b0700c127b1@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_49283_22244395.1224853417175 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Oct 24, 2008 at 3:55 PM, Thomas McKiernan wrote: > How about a lock manager impl independent of any particular store's impl. > It could be abstract if necessary. > > Basically, this has a hierarchy of classes (beans) hard coded. > If you use a store to access a bean then the store impl's tran calls into > the independent lock manager. I feel this is a kind hack for the problem. And also as Andrew has mentioned this won't work in a distributed environment. For me the correct solution is to go through all the transactions and make an order of which transactions access the beans. But apparently this is also seems to be difficult since a lot of transactions has start and commits. So have to think bit more. thanks, Amila. > > Any attempt to enlist outside of the locking hierarchy results in a hard > runtime error and a rollback of the tran. > > Is this too naive? > > ---------------------------------- > Thomas McKiernan > > WebSphere Messaging Development, > IBM United Kingdom Limited > > Internal Phone: 248241 > External Phone: +44 (0)1962 818241 > Mobile: +44 (0)789 1737497 > Email: MCKIERNA@uk.ibm.com > > Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 > 2JN > > > Caminante, no hay camino > Se hace camino al andar. > ("Walker, there is no path; the path is made by walking.") Antonio > Machado > > > > From: > Andrew K Gatford/UK/IBM@IBMGB > To: > "Amila Suriarachchi" > Cc: > "sandesha-dev@ws.apache.org" > Date: > 24/10/2008 11:07 > Subject: > Re: Sandesha2 synchronization and dead lock handling. > > > > 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. > > 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 : gatfora@uk.ibm.com > > > > From: > "Amila Suriarachchi" > To: > "sandesha-dev@ws.apache.org" > 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 > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: sandesha-dev-help@ws.apache.org > > > > > > > > > > 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/ ------=_Part_49283_22244395.1224853417175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Oct 24, 2008 at 3:55 PM, Thomas McKiernan <MCKIERNA@uk.ibm.com> wrote:
How about a lock manager impl independent of any particular store's impl.
It could be abstract if necessary.

Basically, this has a hierarchy of classes (beans) hard coded.
If you use a store to access a bean then the store impl's tran calls into
the independent lock manager.

I feel this is a kind hack for the problem. And also as Andrew has mentioned this won't work in a
distributed environment.
For me the correct solution is to go through all the transactions and make an order of which
transactions access the beans. But apparently  this is also seems to be difficult since a lot
of transactions has start and commits.
So have to think bit more.

thanks,
Amila.




Any attempt to enlist outside of the locking hierarchy results in a hard
runtime error and a rollback of the tran.

Is this too naive?

----------------------------------
Thomas McKiernan

WebSphere Messaging Development,
IBM United Kingdom Limited

Internal Phone: 248241
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: MCKIERNA@uk.ibm.com

Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21
2JN


Caminante, no hay camino
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.")  Antonio
Machado



From:
Andrew K Gatford/UK/IBM@IBMGB
To:
"Amila Suriarachchi" <amilasuriarachchi@gmail.com>
Cc:
"sandesha-dev@ws.apache.org" <sandesha-dev@ws.apache.org>
Date:
24/10/2008 11:07
Subject:
Re: Sandesha2 synchronization and dead lock handling.



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.

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 : gatfora@uk.ibm.com



From:
"Amila Suriarachchi" <amilasuriarachchi@gmail.com>
To:
"sandesha-dev@ws.apache.org" <sandesha-dev@ws.apache.org>
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







---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org









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/
------=_Part_49283_22244395.1224853417175--