[jboss-dev-forums] [Design of JBoss Transaction Services] - Re: JBAS-5801 - Locking in 2PC

[jhalliday]

> What we really want to do is make sure that end() blocks
> at tx timeout until the current user operation has completed.

I'd argue that's exactly what we want to avoid. One use of a tx timeout is to ensure apps don't get stuck due to e.g. slow db queries. If I issue e.g. a SELECT inside a tx and that tx has a timeout, I want it to timeout promptly, not block on the db operation. Likewise for sending or receiving messages. That's part of the reason JBossTS uses a background thread for timeouts.  Sure some resource managers have explicit support for configuring timeouts on potentially long running operations, but it's not required.

I'd say it's up to the resource manager's driver code to decide how to handle the situation. If it's got one thread doing a business logic operation in a tx when another thread is trying to terminate that tx, it can either block internally (I've seen the MS SQL driver do that, queuing the end to go over the same TCP/IP connection when the SELECT eventually returns) or e.g. throw an exception on the business logic thread.

That said, one option may be to make this configurable at the JCA level. Allow e.g. -ds.xml files to contain an option for how the JCA should behave - delegate to the driver as I describe, block as you suggest, or even explicitly interrupt the business logic and throw an exception as some users seem to expect. The last one of course is risky, it may mess up the underlying driver.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166934#4166934

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166934