Re: summary of new features in JDBC 3.0

On Wednesday 27 October 2004 17:16, Oliver Jowett wrote:
> > * Connection pool configuration
>
> What does this entail?

Section 3.1 (p. 21) of the spec says,

| * Connection pool configuration
|
| Defined a number of properties for the ConnectionPoolDataSource
| interface. These properties can be used to describe how
| PooledConnection objects created by DataSource objects should be
| pooled.

From my cursory reading of some of the sections that seem relevant, I
think this means the following. Section 9.4.1 "DataSource Properties"
(p. 58) defines the following DataSource properties:

TABLE 9-1 Standard Data Source Properties

+------------------------------------------------------------------------+
| Property Name | Type | Description |
|-----------------+--------+---------------------------------------------|
| databaseName | String | name of a particular database on a server |
|-----------------+--------+---------------------------------------------|
| dataSourceName | String | a data source name; used to name an |
| | | underlying XADataSource object or |
| | | ConnectionPoolDataSource object when |
| | | pooling of connections is done |
|-----------------+--------+---------------------------------------------|
| description | String | description of this data source |
|-----------------+--------+---------------------------------------------|
| networkProtocol | String | network protocol used to communicate with |
| | | the server |
|-----------------+--------+---------------------------------------------|
| password | String | a database password |
|-----------------+--------+---------------------------------------------|
| portNumber | int | port number where a server is listening for |
| | | requests |
|-----------------+--------+---------------------------------------------|
| roleName | String | the initial SQL rolename |
|-----------------+--------+---------------------------------------------|
| serverName | String | database server name |
|-----------------+--------+---------------------------------------------|
| user | String | user 's account name |
+------------------------------------------------------------------------+

In addition to these, Section 11.7 "ConnectionPoolDataSource
Properties" (p. 78), defines these:

TABLE 11-1 Standard Connection Pool Properties

+------------------------------------------------------------------------+
| Property Name | Type | Description |
|-----------------+------+-----------------------------------------------|
| maxStatements | int | The total number of statements that the pool |
| | | should keep open. 0 (zero) indicates that |
| | | caching of statements is disabled. |
|-----------------+------+-----------------------------------------------|
| initialPoolSize | int | The number of physical connections the pool |
| | | should contain when it is created |
|-----------------+------+-----------------------------------------------|
| minPoolSize | int | The number of physical connections the pool |
| | | should keep available at all times. 0 (zero) |
| | | indicates that connections should be created |
| | | as needed. |
|-----------------+------+-----------------------------------------------|
| maxPoolSize | int | The maximum number of physical connections |
| | | that the pool should contain. 0 (zero) |
| | | indicates no maximum size. |
|-----------------+------+-----------------------------------------------|
| maxIdleTime | int | The number of seconds that a physical |
| | | connection should remain unused in the pool |
| | | before the connection is closed. 0 (zero) |
| | | indicates no limit. |
|-----------------+------+-----------------------------------------------|
| propertyCycle | int | The interval, in seconds, that the pool |
| | | should wait before enforcing the current |
| | | policy defined by the values of the above |
| | | connection pool properties |
+------------------------------------------------------------------------+

> Aren't connection pools in the realm of the appserver?

Perhaps. I can neither confirm nor deny untill I read the spec, which I
haven't done yet.

> > * Making internal updates to the data in Blob and Clob objects
>
> I assume this is the positioned write stuff? Not implemented, but
> doesn't look too hard to do. See the todo list.

Yes, I think you're right. The spec says (Section 3.1):

| * Making internal updates to the data in Blob and Clob objects
|
| Added methods to allow the data contained in Blob and Clob objects
| to be altered.

They appear to be talking about these added methods:
http://people.redhat.com/~vadimn/scratch/pgsql-jdbc/api-diff/java.sql.Blob.html
http://people.redhat.com/~vadimn/scratch/pgsql-jdbc/api-diff/java.sql.Clob.html

> > * Transform groups and type mapping
>
> If this is the SQL type maps stuff, then not implemented. Kris is
> working on SQLInput/SQLOutput implementations that would allow this
> to be implemented. See the todo list.

I'm not sure what this is about. First time I've ever heard of
"transform groups". Section 3.1 says

| * Transform groups and type mapping
|
| Described the effect of transform groups and how this is
| reflected in the metadata.

Section 17.5 "Effect of Transform Groups" goes on to say

| Transform groups (SQL99) can be used to convert a user-defined SQL
| type into predefined SQL types. This transformation is performed
| by the underlying data source before it is returned to the JDBC
| driver.
|
| If transform groups are used for a user-defined type, and the
| application has not defined a mapping for that type to a Java
| class, then the ResultSetMetaData method getColumnClass should
| return the Java class corresponding to the data type produced by
| the transformation function (that is, String for a VARCHAR).

> > * Relationship between the JDBC SPI (Service Provider Interface) and
> > the Connector architecture
>
> I don't think this imposes any implementation requirements on the driver?

I think it does, if you choose to implement what Section 19.2 refers
to as the "Mapping Connector System Contracts to JDBC Interfaces".

Thanks for your answers.

Vadim