[jbossts-issues] [JBoss JIRA] (JBTM-2394) Transaction Reaper "abuses" in-use connection, leading to RPC protocol corruption
Christian von Kutzleben (JIRA)
issues at jboss.org
Fri May 8 09:58:45 EDT 2015
[ https://issues.jboss.org/browse/JBTM-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066518#comment-13066518 ]
Christian von Kutzleben commented on JBTM-2394:
"Alternatively, it would be possible for an XAResource implementation to detect concurrent access and use multiple (internal) connections to the database if that is a requirement of the implementation. "
I'm afraid, that a separate thread to connection mapping would make our XAResource implementation pretty unmaintainable.
Two threads attached to the same Xid is a very special corner case (btw. the reaper does detect and report this in the log),
it would be easy for us to implement a separate physical connection, if the reaper could identify itself as a "special" thread.
"A caller invokes TX::enlist(XAResource). Callers do not provide us with "connections" or factories (I quote the word to signify it draw out how these can be JDBC/JMS/etc) to attempt to obtain an XAR from."
Yes, that is indeed a problem of the JTA. I totally agree with you, that it is a technical problem to acquire an XAResource for such purposes,
IMO JTA should be updated to provide such functionality, maybe a simple clone() specification for XAResource would be sufficient.
(Btw. I updated my previous comment to include XAConnection references, while you were writing your reply)
> Transaction Reaper "abuses" in-use connection, leading to RPC protocol corruption
> Key: JBTM-2394
> URL: https://issues.jboss.org/browse/JBTM-2394
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> The scenario is as follows:
> An regular JBoss application thread uses the connection associated with an XAResource for it's work with the database backend. Start(xid) had been invoked, which means, the associated connection is "switched" to that xid. After finishing work, the regular JBoss application thread would eventually call end(xid, TMSUCCESS).
> The application executes a query that takes longer than the configured timeout.
> The work with the database is done via database specific RPC invocations, caused by a enterprise bean (which uses the JPA API and the JPA implementation eventually talks to the database via the database protocol).
> The (lower-level) connection is a TCP/IP connection, and
> the RPC protocol if of the form: "send data to server, then wait for server reply"
> At this point it should be clear, that the TCP/IP connection should not be shared by another thread whilst in the middle of an RPC invocation, because neither does the database server expect any data at this moment on this particular TCP/IP connection nor does it work, that then 2 threads wait on the same socket to receive a reply. (E.g. a ClosedByInterruptException is likely, there might be other error though, depending how wrong data is interpreted, e.g. BufferUnderflowException).
> Unfortunately, this is exactly the behavior of the JBoss "Transaction Reaper" thread, that uses the very same XAResource, that had been used by the regular JBoss application thread and is currently associated to a connection, "switched" to the current xid.
> By definition of the XA specification, any other XAResource could be used to terminate that transaction branch, and it would be fine, if the transaction reaper thread would use any XAResource (regular one, or one from our recovery module) to do that.
> This is a conceptual flaw of the transaction reaper implementation, and we can't implement a workaround (except extremely silly things like reaper thread recognition by comparing thread names ...)
> We could synchronize access to the TCP/IP connection, to not allow another thread communication, while another thread is active doing so, however, that kind of defeats the purpose of the reaper thread, as it would be blocked indefinitely.
This message was sent by Atlassian JIRA
More information about the jbossts-issues