db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3313) JDBC client driver statement cache
Date Wed, 16 Jan 2008 17:50:37 GMT

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


Mime
View raw message