ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucente, Richard D" <>
Subject RE: Sandesha2 synchronization and dead lock handling.
Date Fri, 24 Oct 2008 13:05:09 GMT
If it's helpful, my company had some difficulty completing a persistence
implementation for sandesha2-1.2.  What we observed was the inmemory
solution appears to enforce pessimistic row locking and the serializable
transaction isolation level.  Once beans are enlisted in a transaction,
all other threads attempting to access the bean block until the bean is
released from its transaction.  It's not possible to implement  a
persistence solution without combing through the inmemory




From: Amila Suriarachchi [] 
Sent: Friday, October 24, 2008 9:04 AM
To: Thomas McKiernan
Cc: Andrew K Gatford;
Subject: Re: Sandesha2 synchronization and dead lock handling.



On Fri, Oct 24, 2008 at 3:55 PM, Thomas McKiernan <>

How about a lock manager impl independent of any particular store's
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
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.


	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
	Mail Point 211, IBM, Hursley Park, Winchester, Hampshire,
England, SO21
	Caminante, no hay camino
	Se hace camino al andar.
	("Walker, there is no path; the path is made by walking.")
	Andrew K Gatford/UK/IBM@IBMGB

	"Amila Suriarachchi" <>


	"" <>

	24/10/2008 11:07
	Re: Sandesha2 synchronization and dead lock handling.

	I went through similar pain when implementing a StorageManager
	encountered a number of deadlocks similar to the ones that you
	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
	Telephone :
	Internal (7) 245743
	External 01962 815743
	Internet :
	"Amila Suriarachchi" <>
	"" <>
	24/10/2008 10:30
	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
	supports isolated transactions.
	To synchronize these beans the transactions must be completely
	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
	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
	problems? Can someone
	have a better idea of Sandesha2 Design shed some light on this?
	Amila Suriarachchi
	WSO2 Inc.
	Unless stated otherwise above:
	IBM United Kingdom Limited - Registered in England and Wales
with number
	Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6 3AU

	To unsubscribe, e-mail:
	For additional commands, e-mail:

	Unless stated otherwise above:
	IBM United Kingdom Limited - Registered in England and Wales
with number
	Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6 3AU

Amila Suriarachchi
WSO2 Inc.

View raw message