Results 1 to 5 of 5

Thread: retry after StaleConnectionException

  1. #1
    Join Date
    Jun 2005
    Location
    Germany/Berlin
    Posts
    5

    Default 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?

    thanks,
    Alex.

  2. #2
    Join Date
    Jan 2005
    Location
    Bucharest, Romania
    Posts
    5,403

    Default

    You can define an interceptor which can do this for you and hook it with TransactionProxyFactoryBean.
    Costin Leau
    SpringSource - http://www.SpringSource.com- Spring Training, Consulting, and Support - "From the Source"
    http://twitter.com/costinl
    Please use [ c o d e ] [ / c o d e ] tags

  3. #3
    Join Date
    Feb 2005
    Location
    Boston, MA
    Posts
    1,142

    Default

    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:

    Code:
    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;;
          &#125;
          catch &#40;StaleConnectionException e&#41; &#123;
            // Escape out of # of retries has been reached
            if &#40;i >= retry&#41;
              throw e;
          &#125;
        &#125;
      &#125;
    &#125;

  4. #4
    Join Date
    Jun 2005
    Posts
    1

    Default

    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?

    thanks!

  5. #5
    Join Date
    Feb 2005
    Location
    Boston, MA
    Posts
    1,142

    Default

    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.

Similar Threads

  1. recovering from SQL connection loses...
    By ElPapa in forum Data
    Replies: 10
    Last Post: Oct 22nd, 2007, 05:45 AM
  2. Replies: 12
    Last Post: Feb 15th, 2007, 12:21 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •