At 08:58 AM 6/2/00 -0700, Glebas Paulevicius wrote:

>
>>Object life times are managed with addRef() and release(). When
>>the use count (decremented by release()) goes to zero, the object
>>joins the great bit bucket in the sky.
>
>addRef - decRef, attach - detach, ... - release
>

AddRef/DecRef is probably more consistent. I lifted addRef/release
from COM which undoubtably lifted it from DCE. I did change the
capitalization to conform with Java conventions. It's arbitrary,
so lets go with the flow.

>>The method close(), when present, can be used to release any context
>>or resources associated with the object but without deleting the
>>object.
>
>flush() is better in such context.

Probably. But JDBC uses close() and I want to use their documentation.

>
>>All objects are automatically closed, if necessary, prior to
>>deletion.
>
>Agreed.
>
>
>>I will also redefine release() to return the post release use
>>count of the object. A return of zero means the object is history.
>>A client that wants to force release must loop decrementing the
>>use count to zero.
>
>Oops! This will violate the other client's rights to the object!
>What is the reason for client to want to force the delete?
>

A high level exception handler may want to wipe out all references
from a subsystem without elaborate cleanup code. There are better
ways to do this, but involves building a set of wrappers for the
API classes just to track use counts. I think it makes sense to
give folks a break by making it accessible (though reasonable people
may differ).

>
>Jim, I have something deep inside me against having
>Connection object in "unconnected" mode!
>The fact that Connection object is created should
>MEAN - we are connected!
>Please, avoid object modes if possible.
>

Point well taken. Realistically, however, eliminating the
unconnected state would virtually dictate a data source
driver class to create connections and databases. Ultimately,
however, the driver class would be doing exactly the same
thing we're doing now but hiding the details.

Here is the JDBC driver class. Do you think we should add it?

public interface Driver {

/**
* Try to make a database connection
to the given URL.
* The driver should return "null" if it realizes it
is the wrong kind
* of driver to connect to the given URL. This will
be common, as when
* the JDBC driver manager is asked to connect to a
given URL it passes
* the URL to each loaded driver in turn.
*

* <P>The driver should raise a SQLException if it is the right
*
driver to connect to the given URL, but has trouble connecting to
*
the database.
*
* <P>The java.util.Properties argument can be
used to passed arbitrary
* string tag/value pairs as connection
arguments.
* Normally at least "user" and "password" properties should
be
* included in the Properties.
*
* @param url The URL of
the database to connect to
* @param info a list of arbitrary string
tag/value pairs as
* connection arguments; normally at least a "user"
and
* "password" property should be included
* @return a
Connection to the URL
* @exception SQLException if a database-access
error occurs.
*/
Connection connect(String url,
java.util.Properties info)
throws SQLException;

/**
*
Returns true if the driver thinks that it can open a connection
* to
the given URL. Typically drivers will return true if they
*
understand the subprotocol specified in the URL and false if
* they
don't.
*
* @param url The URL of the database.
* @return
True if this driver can connect to the given URL.
* @exception
SQLException if a database-access error occurs.
*/
boolean
acceptsURL(String url) throws SQLException;


/**
* <p>The
getPropertyInfo method is intended to allow a generic GUI tool to
*
discover what properties it should prompt a human for in order to get

* enough information to connect to a database. Note that depending on

* the values the human has supplied so far, additional values may become

* necessary, so it may be necessary to iterate though several calls

* to getPropertyInfo.
*
* @param url The URL of the database to
connect to.
* @param info A proposed list of tag/value pairs that will
be sent on
* connect open.
* @return An array of
DriverPropertyInfo objects describing possible
* properties.
This array may be an empty array if no properties
* are
required.
* @exception SQLException if a database-access error
occurs.
*/
DriverPropertyInfo[] getPropertyInfo(String url,
java.util.Properties info)
throws SQLException;


/**
* Get
the driver's major version number. Initially this should be 1.
*/

int getMajorVersion();

/**
* Get the driver's minor version
number. Initially this should be 0.
*/
int getMinorVersion();



/**
* Report whether the Driver is a genuine JDBC COMPLIANT (tm)
driver.
* A driver may only report "true" here if it passes the JDBC
compliance
* tests, otherwise it is required to return false.
*

* JDBC compliance requires full support for the JDBC API and full
support
* for SQL 92 Entry Level. It is expected that JDBC compliant
drivers will
* be available for all the major commercial databases.

*
* This method is not intended to encourage the development of
non-JDBC
* compliant drivers, but is a recognition of the fact that
some vendors
* are interested in using the JDBC API and framework for
lightweight
* databases that do not support full database
functionality, or for
* special databases such as document information
retrieval where a SQL
* implementation may not be feasible.
*/

boolean jdbcCompliant();
}


Jim Starkey