On 01.03.2012 22:17, Knut Anders Hatlen wrote:
"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.
+1 to using newer and improved APIs.
I don't know if there are users out there that can't yet upgrade to Java
7 and who are seeing this issue - in that case we may end up with three
modules instead of two...
There is talk about tighter synchronization between Java ME and Java SE
releases. It will be interesting to see how that plays out.
--
Kristian
