[
https://issues.apache.org/jira/browse/AMQ-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386641#comment-15386641
]
Gary Tully commented on AMQ-6370:
---------------------------------
The fix for AMQ-2551 is the root cause.
Moving the locking to the transaction context, essentially up a level, will
ensure that the datasource connection handling is always done with the
appropriate lock.
> JDBC message store - jdbc connection pool - potential deadlock with cleanup
> task when pool exhausted
> ----------------------------------------------------------------------------------------------------
>
> Key: AMQ-6370
> URL: https://issues.apache.org/jira/browse/AMQ-6370
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC, Message Store, XA
> Affects Versions: 5.13.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Fix For: 5.14.0
>
>
> There is an read/write lock guarding the cleanup task and other jdbc ops in
> the jdbc message store.
> Typically the read lock is obtained before the connection from the jdbc
> connection pool.
> In the case of xa transactions, the connection is obtained before the read
> lock, in transactioncontext.begin, leaving a window between which readlock
> holders can be blocked pending the connection release.
> If there is a cleanup (and write lock) request before release, the xa
> transaction cannot obtain a read lock and we are stuck.
> Disabling the cleanup task avoids this issue, but that is only an option if
> there are no durable subs or if the durable sub cleanup task can be tackled
> through db admin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
