[
https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559574#action_12559574
]
Bryan Pendleton commented on DERBY-3313:
----------------------------------------
Hi Kristian, thanks for the clarifications. I think I'm understanding the idea
better now.
Did I understand correctly that pooled connections may have prepared statement
caches, but non-pooled connections will not?
Does each pooled connection have its own cache? If I do something like:
Connection c = getPooledConnection();
c.prepareStatement("select * from employee");
then will the behavior depend on whether or not this pooled connection has
previously prepared this statement?
What replacement policy does the statement cache use when it becomes full?
Thanks again for being patient with my questions.
> 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: derby-3313-1a-early_prototype.diff,
> derby-3313-1a-early_prototype.stat, 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.
