This content has been marked as final. Show 1 reply
I understand that this is because the ReaperThread abortes the transaction, because it took too long. Unfortunately, at this point there is still data being transferred to the database. So, the ReaperThread aborts a valid connection!
You may think it's valid, but the TM has no way of knowing. The standards (JTA and OTS) and pretty clear on this: if the timeout goes off then you abort the transaction.
As a workaround I increased the timeout value to 30 minutes, but this leads to the following issues:
1) Eventually someone wants to put a real lot of objects into the database and this may take more than 30 minutes. The ReaperThread will abort this process too. Unfortuanately, it's not possible for us to tell in advance how much time a transaction may need and what would be a good timeout value.
2) If there is a deadlock or something like that, the database is locked for 30 minutes.
It would be better if the ReaperTread would only abort the transaction if the working thread is not transferring data to the database anymore (because of a dead lock for instance). How do I achieve that? Any ideas will be appreciated.
And it gets to know this ... how? What metrics and heuristics should it use to ensure that the transaction does "eventually" roll back? How do you care to merge this with what the standards require? That last one is very important for interoperability and portability.