Description:

We have been discussing this for a long time now and it looks like if there was a mean to time out rollback operation that BaseConnection class does while cleaning up of resources, it could certainly most of the time save system from crashing.

Use case:

Just to clarify on the situation, when the system is heavily bombed with bulk request(mostly on particular days, if it is a vertical solution), there are chances of high lock contention that might lead to more threads waiting. Obviously there are threads that consumes more memory than usual threads, what if these threads are more in number? In the situation of high request volume and more memory consuming threads, JVM calls for the GC. Unfortunately, if there are some explicit close call made on connection which has associated transaction pending, BaseConnection would try rolling it back and you would see traces like below:


====================================

at java/net/SocketInputStream.socketRead0(Native Method)
at java/net/SocketInputStream.read(SocketInputStream.java:140(Compiled Code))
at com/savvion/jdbc/oracle/net8/ddc.b(Bytecode PC:10(Compiled Code))
at com/savvion/jdbc/oracle/net8/ddc.z(Bytecode PC:28(Compiled Code))
at com/savvion/jdbc/oracle/net8/ddc.x(Bytecode PC:127(Compiled Code))
at com/savvion/jdbc/oracle/net8/ddc.h(Bytecode PC:1)
at com/savvion/jdbc/oracle/ddn.c(Bytecode PC:41)
at com/savvion/jdbc/oraclebase/ddcu.a7(Bytecode PC:42)
at com/savvion/jdbc/oracle/net8/ddg.b(Bytecode PC:20(Compiled Code))
at com/savvion/jdbc/oracle/OracleImplConnection.am(Bytecode PC:73(Compiled Code))
at com/savvion/jdbc/oraclebase/BaseConnection.rollback(Bytecode PC:81(Compiled Code))
at com/savvion/jdbc/oraclebase/BaseConnection.m(Bytecode PC:12)
at com/savvion/jdbc/oraclebase/BaseConnection.close(Bytecode PC:8)
at com/savvion/jdbc/oraclebase/BaseConnection.finalize(Bytecode PC:8)
at java/lang/J9VMInternals.runFinalize(J9VMInternals.java:412(Compiled Code))

====================================

Now, that this call was not getting a a signal back for proper rollback from DB, it is still waiting there holding up the finalizer thread where rest of isolated and GC qualified objects eating up the memory remain in the heap because the corresponding cleanup calls are waiting in the queue(to get hold of finalizer thread), eventually leading to memory starvation and crashing the server.

Benefits:


Assuming this to be one scenario, if there was a mean to tell BaseConnection class that rollback didn't get a response back from DB(for example xyz-timeout period of time) and we know waiting on finalizer for this long is costly, just timeout and let others do their job in finalizer, it would save JVM from reaching OOM.


Workarounds:

There is no workaround to this. Administrator and developers can just have JVM memory set to its best and work on reducing locks contention, which is mostly taken care of as far as possible.