Describe the bug
- DynamicProxySupport registers the Statement twice, leading to duplicate entries, where one remains after deregistering the statement. This led to the "Forcing close of pending statement" messages at commit/rollback, despite all statements were closed and also to extended close times due to a growing list of references to statements.
- CoordinatorImp and TransactionStateHandler registers a JdbcRequeueSynchronization for each statement, although the CompositeTransaction and the Proxy is always the same. This led to extended times in commit/rollback
To Reproduce
Steps to reproduce the behavior:
We have programs which are opening and closing statements, sometimes millions of times. What we saw was, that the program itself finished after some time, but the CPU usage was still very high. We found that the time-consuming part was after finishing the main program and in the commit cycle.
Debugging this revealed, that there were millions of JdbcRequeueSynchronization were held in CoordinatorImp and TransactionStateHandler, and it were running thru them executing the notifyBeforeCompletion() and notifySynchronizationsAfterCompletion().
As the registered JdbcRequeueSynchronization objects were all the same in terms of CompositeTransaction and ConnectionProxy, it should be enough to register a JdbcRequeueSynchronization only once per CompositeTransaction and ConnectionProxy, to have all relevant objects in access.
In addition, we found also the issue, that Statements were added twice to the list, so that after each statement a useless reference to the closed statement was held, which was then cleaned up at commit as well. This led to extended close times the more the list grew due to the large number of statements.
As a fix for those issues, we did the following:
- ensure that the JdbcRequeueSynchronization is only registered once by maintaining a LinkedHashSet to check if a JdbcRequeueSynchronization with the current CompositeTransaction and ConnectionProxy was already registered
- Register the Statements in a LinkedHashSet instead of a list and remove the unnecessary call to addStatement method.
Additional context
We were using the version 6.0.0. The issue is also in 6.0.1-SNAPSHOT.
I understand that this project is not intended for support - because bug reports may or may not be considered for inclusion some day (in a future release). If this is issue is important to me then I can go to https://www.atomikos.com/Main/SupportOverview and arrange a paid support subscription.
Describe the bug
To Reproduce
Steps to reproduce the behavior:
We have programs which are opening and closing statements, sometimes millions of times. What we saw was, that the program itself finished after some time, but the CPU usage was still very high. We found that the time-consuming part was after finishing the main program and in the commit cycle.
Debugging this revealed, that there were millions of JdbcRequeueSynchronization were held in CoordinatorImp and TransactionStateHandler, and it were running thru them executing the notifyBeforeCompletion() and notifySynchronizationsAfterCompletion().
As the registered JdbcRequeueSynchronization objects were all the same in terms of CompositeTransaction and ConnectionProxy, it should be enough to register a JdbcRequeueSynchronization only once per CompositeTransaction and ConnectionProxy, to have all relevant objects in access.
In addition, we found also the issue, that Statements were added twice to the list, so that after each statement a useless reference to the closed statement was held, which was then cleaned up at commit as well. This led to extended close times the more the list grew due to the large number of statements.
As a fix for those issues, we did the following:
Additional context
We were using the version 6.0.0. The issue is also in 6.0.1-SNAPSHOT.
I understand that this project is not intended for support - because bug reports may or may not be considered for inclusion some day (in a future release). If this is issue is important to me then I can go to https://www.atomikos.com/Main/SupportOverview and arrange a paid support subscription.