[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Matt Lovett updated SANDESHA2-49:
---------------------------------
Attachment: detectSandeshaDeadlock.patch
This patch adds deadlock detection into the in-memory storage manager. It can't
do much more than throw an exception at this point, but if we ever put rollback
support in then it will be fairly robust. The logging should also help us
pinpoint which threads are blocking each other, and why.
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch,
> deadlockAck.patch, deadlockAck2.patch, detectSandeshaDeadlock.patch,
> lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate
> locking. This leads to lots of potential holes - for example if 2 reliable
> messages arrive very close together we could mess up the sequence ack ranges.
> A general solution seems to be to lock each bean on first access, and release
> it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
