Optimize client side LOB release mechanism by reducing the number of round-trips
--------------------------------------------------------------------------------
Key: DERBY-3575
URL: https://issues.apache.org/jira/browse/DERBY-3575
Project: Derby
Issue Type: Improvement
Components: Network Client
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
The current mechanism for freeing LOB locators from the client driver, is to
invoke a stored procedure for each LOB locator every time the result set
position is changed. This can potentially result in a number of round-trips to
the server.
The mechanism can easily be optimized by adding a stored procedure that takes a
list of LOB locators and frees them all. The level of optimization can be
tweaked by changing the timing of the stored procedure invocation, and this
must also be balanced with regards to resource consumption on the server. The
more LOB locators we collect on the client before we send the release request,
the more memory is bound to LOB resources on the server.
Possible release points:
* on each result set positioning
* when a threshold value is reached
* on result set close
* when Blob/Clob.free is called (problematic, as the Blob/Clob is detached
from the result set)
There are some compatibility issues to consider, and the client driver will
most likely have to implement both the naive and the optimized mechanism. For
this reason, it might be good if the release mechanism can be tightly
encapsulated (for instance within LOBStateTracker).
Note that piggy-backing the locators would be the most effective solution, but
it is likely that implementing it requires more time and thus I'm reluctant to
do so this close to the release. I'm saying this because we do need a fix to go
into 10.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
