1 Reply Latest reply on Jul 8, 2003 5:50 AM by adrian.brock

    JBoss 2.4.8 Threading, Transactions and Exceptions

    strathound

      Hello,


      Just throwing a problem I'm trying to figure out over the wall in the slight chance someone can assist.

      I'm using JBoss 2.4.8 (don't ask). I have a session bean that uses container managed transactions, setup like:


      <display-name>OrderSystem</display-name>
      <ejb-name>OrderSystem</ejb-name>
      com.landsafe.order.ejb.OrderSystemHome
      com.landsafe.order.ejb.OrderSystem
      <ejb-class>com.landsafe.order.ejb.OrderSystemBean</ejb-class>
      <session-type>Stateless</session-type>
      <transaction-type>Container</transaction-type>


      In order to simulate a severe network error and test our retry logic, I step through my application in a debugger, let the processOrder() transaction begin, then yank out my network connection. The DAO layer gets a java.net.SocketException as one would expect. It then rethrows a SQL exception back to the session bean. Upon receiving the SQLException, the EJB throws an EJBException so that the container knows to rollback the transaction. This bubbles up to the calling class as a RemoteException, in compliance with the spec. I then handle this appropriately there for the retry logic, and this works ... most of the time.

      However, when I unplug the network connection (and in rare scenarios in production), the client code NEVER sees the RemoteException. In the debugger, I can see it throw the EJBException, but it never shows up in the calling class, even if I'm catching Throwable.

      We have several theories. The first is that the socket that was opened for remote communication between the client object, the stub object, and the remote bean residing in the container is required to be available in order to successfully serialize the RemoteException back to the client. I'm running everything locally, so this seems ... odd. The second theory is based on the fact that we noticed that JBoss is running both the client code (a Business Delegate on the server side) and the EJB inside the same thread. We have theorized that the container just cleans up the thread when it appears to be locked and just cleans it up and execution stops on that thread. Thus we don't see any additional processing.

      In either case, we are pretty sure this isn't the way it's supposed to work. The EJB stub object should time out after a certain amount of time and indicate to the client that it no longer is able to talk to the remote system.

      This is already a long long topic. I can post the exact code we are using if that helps. But it's pretty straightforward. At this point, I have to assume this is a bug in JBoss 2.4.8. If anyone has any thoughts on this, please let me know.

      Thanks,

      Michael