1 Reply Latest reply on Mar 15, 2004 9:31 AM by Adrian Brock

    'Operation interrupted' exception

    Jayasudan.M Newbie


      Problem description:
      A container managed bean transaction, method call that has 'select...for update' statement is delayed for some reason. Probably a DB lock or resource un-availability. Not sure what causes this.
      Because of this delay, the bean transaction gets timed out.
      Hence the thread is interrupted by Jboss and gets 'Operation interrupted' exception.
      This exception is generally followed by 'Protocol violation', 'Bigger type length than Maximum' and / or 'Refcursor value is invalid' exceptions.

      When and why will the 'Operation interrupted' exception be thrown?
      Can we ignore the other exceptions listed above which are thrown after 'Operation interrupted' exception?
      There are other threads in the same log which has actually taken almost 9mins to complete the transaction but still were successfully completed without 'Operation interrupted' exception. Not able to understand this behaviour.

      Environment details:
      Jboss 3.2.3 on Sun Solaris 2.8
      Oracle 8.1.6
      JDK 1.4.2_03
      Max DB connection pool size: 50
      Transaction time out is set as 5 mins (300 secs)

      Exception from server log:

      {some other threads executing the same query as above have successfully completed the transaction indicating there is no actual DB lock!}
      <11:21:58.678> [Thread Pool Worker-0] EXCEPTION in <DBLogSupportNotificationDAO::getFamilyDetails()>
      ...... <Exception Message> : Io exception: Operation interrupted -
      ...... <Exception Stack Start>
      java.sql.SQLException: Io exception: Operation interrupted
      ...... <Exception Stack Close>

        • 1. Re: 'Operation interrupted' exception
          Adrian Brock Master

          The operation interrupted means the transaction timeout interrupted the thread.
          Looks like your Oracle8 driver doesn't handle this very well.
          What it should do is close the connection rolling back the db transaction.

          The fact that some transactions lasted for 9 minutes sounds like it completely
          ignores the interrupt in some circumstances. Either that or your code does.

          I bet you'll find it didn't commit, since it was marked for rollback 4 minutes before.

          Your underlying problem sounds like a deadlock to me.