Announcement Announcement Module
No announcement yet.
retry after StaleConnectionException Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • retry after StaleConnectionException

    We handle our transactions with the help of the Springframework and hibernate. Eg. our class OrderService class is wrapped by a spring transaction proxy class.

    On Websphere 5.1 we get sometimes a StaleConnectionException in a business method of the OrderService class.

    Currently we call the methods of the OrderService from Struts. But I dont want to catch StaleConnectionException in Struts actions and then call the buisiness method again.

    Without spring I could rollback the transaction, get a new one and retry the business method.

    Is there a way in Spring to automate this process?
    Is the proxy class able to catch an StaleConnectionException , then get a new one from Hibernate and finally call ma business method with a new connection again?


  • #2
    You can define an interceptor which can do this for you and hook it with TransactionProxyFactoryBean.


    • #3
      Since you are already using a proxy, this shouldn't be that hard. Basically you need to implement your own interception around advice which catches and retries the operation. See here

      You would make sure this advice is wrapped around the transactional interceptor so the transaction gets rolled back before you retry the operation. It would look something like this:

      public class RetryIntercetpor
          implements MethodInterceptor {
        private int retry = 0; // Defaults to no retries, bombs out on first failure.
        public void setRetry(int retry) {
          this.retry = retry;
        Object invoke(MethodInvocation invocation) throws Throwable {
          for &#40;int i = 0; i < retry; i++&#41; &#123;
            try &#123;
              return invocation.proceed&#40;&#41;;
            catch &#40;StaleConnectionException e&#41; &#123;
              // Escape out of # of retries has been reached
              if &#40;i >= retry&#41;
                throw e;


      • #4
        I understand that for a transaction it should be returned to the caller ( the one who initiates the XA_TRAN) for example a StatelessSession Bean starting the XA_TRAN to the datat source, that makes since to rollback and be caught.

        But for transactions that are not under XA and are not part of a transaction at all, they are simply a read from the database, let's say a nonpersist "search" wouldn't this be handled at the data access layer that is making the connection to the DB? If the purge policy for the dataSource in Websphere Application Server is set to ENTIRE_POOL, upon receiving a staleconnectionexception the pool would be cleared, after the exception is caught in the datalayer, it then retries with one of the "NEW" connections? Why would the business logic care about a "staleconnectionexception" in this case?
        Please keep in mind I am referring to NON-transactions - there is no ejb involved

        What are your thoughts?



        • #5
          Not all data layers do this automatically. If a database connection is lost, the retry is not always automatic. The caller will get the exception, and it would be up to the client code to handle it. Putting this behavior into an aspect makes it so you only have to write this code once.