db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "Derby3192Writeup" by DyreTjeldvoll
Date Mon, 11 Feb 2008 17:37:21 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DyreTjeldvoll:
http://wiki.apache.org/db-derby/Derby3192Writeup

------------------------------------------------------------------------------
  
  = Goal =
  
- The patch implements caching of the isolation level in the client
+ The patch implements caching of the isolation level and the current
- driver. The caching lets the client driver execute
- `getTransactionIsolation()` without a round-trip to the server. It would
- also let the `setTransactionIsolation()` be "short-circuited" (and avoid
- a round-trip), in the case where the new isolation level is equal to
- that cached in the client. The latter optimization is not part of this
- patch since it would mean that `setTransactionIsolation()` no longer
- would be guaranteed to commit the current transaction. Including it
- would have made the client driver behave the same way as the embedded
- driver in this respect, but unfortunately it would also mean that a
- number of tests expecting the old behavior would fail.
+ schema name in the client driver. The caching lets the client driver
+ execute `getTransactionIsolation()` and a new method called
+ `getCurrentSchemaName()` (which is not part of the
+ `java.sql.Connection` interface), without a round-trip to the
+ server. 
+ 
+ It would also let the `setTransactionIsolation()` be
+ "short-circuited" (and avoid a round-trip), in the case where the new
+ isolation level is equal to that cached in the client. The latter
+ optimization is not part of this patch since it would mean that
+ `setTransactionIsolation()` no longer would be guaranteed to commit
+ the current transaction. Including it would have made the client
+ driver behave the same way as the embedded driver in this respect, but
+ unfortunately it would also mean that a number of tests expecting the
+ old behavior would fail.
  
  
  = Motivation =
  
  One would ordinarily not expect the performance of
- `getTransactionIsolation()` to be critical. However, the use of
- connection pools (commonly found in application server environments),
- invalidates this assumption. 
+ `getTransactionIsolation()` or `getCurrentSchemaName()` to be
+ critical. However, the use of connection pools (commonly found in
+ application server environments), invalidates this assumption.
  
  A connection pool works by keeping a limitied number of (open)
  connections in a pool and letting application (threads) share the
@@ -36, +41 @@

  obatined from a call to `DriverManager.getConnection()` (or
  `DataSource.getConnection()`). 
  
- In the case of the isolation level the connection pool manager can
- either unconditionally set the isolation level back to its default
- value when a connection is returned to the pool (alternatively just
- before it is returned from the pool), or it can query the connection
- for its isolation level setting and just change it if it is different
- from the default. In either case, a driver that doesn't cache the
- isolation level will be forced to make an additional round-trip to the
+ The connection pool manager can either unconditionally set the
+ isolation level back to its default value when a connection is
+ returned to the pool (alternatively just before it is returned from
+ the pool), or it can query the connection for its isolation level
+ setting and just change it if it is different from the default. In
+ either case, a driver that doesn't cache the isolation level will be
+ forced to make an additional round-trip to the server each time a
- server each time a connection enters (or leaves) the connection pool.
+ connection enters (or leaves) the connection pool.
+ 
+ A cheap way to get the current schema for a connection is important
+ when implementing a [https://issues.apache.org/jira/browse/DERBY-3313
+ statement cache] on the client side, since PreparedStatement objects
+ only can be re-used if the statement text is identical, '''and''' the
+ schema used during compiliation and the current schema are identical. 
  
  
  = The Stale Cache Problem =
  
- Caching the isolation level in the context of JDBC is simple, and
+ Caching the isolation level and current schema in the context of JDBC
+ is simple, and prior to
- prior to [http://issues.apache.org/jira/browse/DERBY-1148 DERBY-1148]
+ [http://issues.apache.org/jira/browse/DERBY-1148 DERBY-1148] the
- the client driver would cache the isolation level and only update its
+ client driver would cache the isolation level and only update its
  cache whenever `setTransactionIsolation()` was called. As explained in
  [http://issues.apache.org/jira/browse/DERBY-1148 DERBY-1148] this is
  not sufficient, as the isolation level can change without
- `setTransactionIsolation()` being called (XA, SQL, stored procedures, and
+ `setTransactionIsolation()` being called (XA, SQL, stored procedures,
- functions). In all of theses cases the cached isolation level becomes
- stale (different from the actual isolation level in the embedded
+ and functions). The current schema can not be modified from JDBC, but
+ it can be changed both from SQL and in stored procedures and functions.
+ 
+ In all of theses cases the cached values become stale (different from
+ the actual isolation level and current schema in the embedded
- connection used by the NetworkServer.
+ connection used by the NetworkServer).
+ 
+ 
  
  
  = Solutions to the Stale Cache Problem =

Mime
View raw message