Re: summary of new features in JDBC 3.0 - Mailing list pgsql-jdbc
From | Vadim Nasardinov |
---|---|
Subject | Re: summary of new features in JDBC 3.0 |
Date | |
Msg-id | 200410271855.03938@vadim.nasardinov Whole thread Raw |
In response to | Re: summary of new features in JDBC 3.0 (Oliver Jowett <oliver@opencloud.com>) |
Responses |
Re: summary of new features in JDBC 3.0
|
List | pgsql-jdbc |
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
pgsql-jdbc by date: