[
https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559609#action_12559609
]
Kristian Waagan commented on DERBY-3313:
----------------------------------------
Bryan wrote:
> Did I understand correctly that pooled connections may have prepared statement
> caches, but non-pooled connections will not?
Yes, this is correct. Whether a pooled connection will have a cache or not is
controlled by the method setMaxStatements of the data source. A value of zero
disables statement pooling. The size of the cache/pool is determined at
connection creation time only.
I need to clarify the situation for XA connections.
> 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?
Yes, each pooled connection will have its own cache.
There is no caching across pooled connections. A pooled connection is, or is a
wrapper for, a physical connection.
Nitpick:
The illustrative code can be a tad misleading. What happens in a connection
pool, is more like this:
ConnectionPoolDataSource cpDs = new ClientConnectionPoolDataSource();
PooledConnection pooledCon = cpDs.getPooledConnection();
Connection clientCon = pooledCon.getConnection();
// Client uses this connection and eventually closes it.
Connection nextClientCon = pooledCon.getConnection();
// Next client does its things.
// and so on...
pooledCon.getConnection() returns a logical connection. In my current approach,
this will return an instance of either LogicalConnection (no statement cache)
or CachingLogicalConnection (with statement caching).
> What replacement policy does the statement cache use when it becomes full?
I have planned to throw out the oldest statement of the cache. The approach is
to take statements out of the cache when it is used. If the statement is put
into the cache again, it will be inserted as the newest element. The oldest
element will thus also be the least frequently used element.
Implementation wise, I plan to use a LinkedHashMap. This has support for both
insertion-based and access-based ordering, and it has a mechanism that is very
easy to use for throwing out elements (override method removeEldestElement).
> 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.
