"Bergquist, Brett" <[email protected]> writes: > Looking at a heap dump today, it does appear the instances stabilize > so the growth is not unbounded but rather a function of the > transaction rate as indicated. That is good! > > I do think that the proposed more complex solution would be better. > Looking at the patch attached to the issue, one might have a separate > timer be available from the factory for XA transactions so as to not > affect the generic statement timeout capability. Then the more > complex solution could do something like call the "purge" every X > cancels or every N seconds for example. Either/both could be > properties that could be configured in derby.properties.
While we're on the topic of complex solutions... :) SingletonTimerFactory is a separate module, and Derby's module management system supports loading different implementations of the module on different platforms. So we could have another version of the module that uses ScheduledThreadPoolExecutor instead of java.util.Timer on the platforms where that class is available. In Java 7, ScheduledThreadPoolExecutor got a new method called setRemoveOnCancelPolicy(), which seems to have been added for this exact reason. Setting a policy on an executor feels a little bit cleaner than periodically purging the timer queue. The downside is that it'll only fix the problem on Java 7 and newer. And that we'll have two modules as long as we need to support CDC/FP. -- Knut Anders
