In order to prevent indefinite locking of resources, the transaction manager will abort in-flight transactions that have not completed after a specified interval. This abort is done by a set of background processes, coordinated by the TransactionReaper. This reaper will roll back transactions without interrupting any threads that may be operating within their scope. This prevents instability that can result from interrupting threads executing arbitrary code. Furthermore, it allows for timely abort of transactions where the business logic thread may be executing non-interruptable operations such as network I/O calls. This approach may, however, cause unexpected behavior in code that is not designed to handle multithreaded transactions. Warning or error messages may be printed from Hibernate or other transaction-aware components as a result of the unexpected transaction status change. These should not affect the transaction outcome. The problem can be minimized by appropriate tuning of the transaction timeout.