> Basically, any RMI-based transport is vulnerable to the problem
of a
> client holding onto an RMI stub that no longer matches the server.
> Do you need to use an RMI connector?
The short answer to this is no -- in fact, in production, per the suggestions of a JBoss
consultant that we'd see better performance with Socket transport, we are using Socket
transport.
The reason we're investigating a switch to RMI is that the RMI transport
"properly" handles aborted transactions, in that it immediately throws an
exception back to the client that the transaction was rolled back. Socket Transport will
not catch that the transaction is rolled back, so the client doesn't get notified --
until the thread completes... assuming it does... and even then, the client only
receives a notice that the long running thread's transaction is dead so, even though
we made you wait for the long running thread to complete, we're only going to give you
an InvalidStateException because the wrapping transaction has timed out.
That said, Socket Transport handles a server bounce quite elegantly. :)
So long answer is that we're trying to find a transport that meets all our needs --
which are pretty simple -- notify client immediately when Transaction times out (some type
of Exception is fine TransactionRolledBack or whatever) AND handle a server restart.
Any advice on what the best approach is to get one of these transports fixed to meet our
needs is very much appreciated.
Thanks, much!
John
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130463#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...