ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <amilasuriarach...@gmail.com>
Subject Re: Sandesha2 synchronization and dead lock handling.
Date Fri, 31 Oct 2008 05:56:00 GMT
On Fri, Oct 24, 2008 at 3:31 PM, Andrew K Gatford <GATFORA@uk.ibm.com>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 : 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
>
>
>
>
>
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Mime
View raw message