ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew K Gatford <GATF...@uk.ibm.com>
Subject Re: Sandesha2 synchronization and dead lock handling.
Date Fri, 24 Oct 2008 11:12:33 GMT
That may work - there are a couple of possible problems that I can see.

For example - if you have a store that is shared with a number of servers 
and the sequence information is shared for all those servers, having an 
independent lock manager would have to be able to cope with negotiating 
with all those servers.

The second possible problem is that even with the independent lock manager 
- depending on the DB and the isolation levels etc, it is possible for 
lock manager to grant a lock, but the DB to fail because it has a table 
locked, or a row locked.  This is why I was interested in what happens 
when running with multiple sequences and using the jdbc store as it could 
suffer from that sort of problem.  Maybe I'm being too pessimistic - 
perhaps it will all just work :)

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:
Thomas McKiernan/UK/IBM@IBMGB
To:
Andrew K Gatford/UK/IBM@IBMGB
Cc:
"Amila Suriarachchi" <amilasuriarachchi@gmail.com>, 
"sandesha-dev@ws.apache.org" <sandesha-dev@ws.apache.org>
Date:
24/10/2008 11:36
Subject:
Re: Sandesha2 synchronization and dead lock handling.



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.

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







---------------------------------------------------------------------
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







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


Mime
View raw message