[
https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557827#action_12557827
]
Kristian Waagan commented on DERBY-3313:
----------------------------------------
Thanks for giving feedback on the overview Dan.
I was not aware of what you state about the cache in the embedded driver, and
this was useful information. I will clarify the wording in the overview, and
also think about the possibility to share code between both drivers.
Just out of curiosity, how much work do you think is saved/avoided by the
current scheme when it comes to re-preparing a statement in the embedded driver?
Are we talking about less then 10%, something like 50% or more than that?
I'm just looking for an indication of how much can be gained from caching JDBC
statement objects in the embedded driver.
Right now I'm not convinced the code can be shared directly and easily. From
what I have seen previously, entering the realm of code sharing between the two
drivers can result in quite a lot more work. I will keep it in the back of my
head though, and try to make the right choices happen if sharing seems feasible.
> JDBC client driver statement cache
> ----------------------------------
>
> Key: DERBY-3313
> URL: https://issues.apache.org/jira/browse/DERBY-3313
> Project: Derby
> Issue Type: New Feature
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: JDBCClientStatementCacheOverview.txt
>
>
> A statement cache in the JDBC client driver will help increase performance in
> certain scenarios, for instance some multi-tier systems using connection
> pooling.
> Please consult the comments and documents attached to this issue for more
> information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
