[jira] Updated: (DERBY-3575) Optimize client side LOB release mechanism by reducing the number of round-trips

["Kristian Waagan (JIRA)" <ji...@apache.org>]

     [ 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:     (was: 10.4.1.0)
                       (was: 10.5.0.0)

After getting feedback from Knut Anders and reconsidering, in addition to the limited time left before the release candidate is produced, I'm strongly thinking about closing this as "Won't fix".

The points Knut Anders raised about code maintenance/complexity and compatibility are very valid and good, in my opinion.
Further, just using the simple release mechanism is still an improvement over the current situation.

Unless someone strongly disagrees, I will close this issue and the subtask DERBY-3577 as "Won't fix".

> 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.