The query must be actively transferring JDBC data back for soft kill to work. If the following conditions are true, FusionReactor will time out the soft kill and upgrade the kill to a thread kill:
- The query is still executing on the database and no results are available (yet)
- The query has executed, but the result set is being transferred in bulk from database to the underlying driver
The second scenario is very common. FusionReactor can't soft kill a JDBC-engaged thread until the J2EE application (e.g. ColdFusion MX) begins reading rows from it, which can only occur after the result set has been transferred from the database.
A common solution to this problem is to have the underlying driver use cursor-driven result sets. The result set is not bulk-transferred over the connection, but remains on the database server. When a row is requested by the J2EE application, the JDBC Driver Wrapper reads this row from the database. There are two major advantages to using cursor-driven result sets:
1. FusionReactor can easily soft kill these requests since they retrieve results row by row
2. The memory burden (the memory required to store the result set) is transferred from the J2EE server (which typically run with tight memory margins anyway) to the database server, where it can be managed much more effectively.
The procedure for instructing your underlying driver to use cursor-driven result sets is different for each driver and server. As an example, the Macromedia MSSQL driver can be switched to cursor mode by adding
to its JDBC URL. A typical wrapped Macromedia MSSQL URL might then be (in a single line):
|Components:||JDBC, Request Managment, Thread Management|
|Last Updated:||19/Jun/07 12:23 PM|
FRS-25: Why doesn’t soft kill always work? (Understanding Soft Kill Limitations)