Some operations in Remoting 3 might be long-running under normal conditions, and thus it is be desirable to provide a means to interrupt them. This is means is provided by way of allowing the synchronous request methods (and, of course, the methods on Future) to throw InterruptedException. Examples are in the Context, FutureReply, and ReplyContext interfaces. However there are also methods that may not be long-running under normal circumstances, but might run long under conditions such as network connection problems or heavily loaded servers. Such methods include the transaction control methods (begin/commit/rollback and the XAResource implementation), and probably a few others as well. So here's the question: should these normally-quick-but-possibly-sometimes-slow methods: a) throw InterruptedException, b) translate the InterruptedException into a RemotingException (and keep the thread's interruption status set), or c) just run uninterruptably (and propagate the thread's interruption status)? Right now the code is a mishmash of all three. :-) The advantage of (a) is that the user's code can be the most "correct" in its handling of interruption. Which is to say, interruption stops execution (more or less) immediately, and is easy to detect. On the other hand, it is pretty unlikely that it will happen, and if there's one good way to annoy users, it is to make them write handlers for things that don't happen often. Option (b) has the advantage of being simpler to code for the user. The operation is still stopped immediately. But it's harder now to figure out that it was due to interruption. Probably the user will never even consider that possibility. I don't know if this is a disadvantage in *practical* terms though. Option (c) is the easiest of all for the user - but it makes it impossible for the user to stop the operation using interruption, in the unlikely event that it runs long. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085281#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...