[
https://issues.apache.org/jira/browse/DERBY-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3575:
-----------------------------------
Fix Version/s: 10.5.0.0
10.4.1.0
Setting fix version to indicate I want to get this in for 10.4.
> 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
> Fix For: 10.4.1.0, 10.5.0.0
>
>
> 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.
