Oracle 5.0 Reference Manual page 2090

relaxAutoCommit
retainStatementAfterResultSetClose
rollbackOnPooledClose
runningCTS13
serverTimezone
statementInterceptors
strictFloatingPoint
strictUpdates
tinyInt1isBit
transformedBitIsBoolean
treatUtilDateAsTimestamp
ultraDevHack
useAffectedRows
useGmtMillisForDatetimes
Connector/J (JDBC) Reference
the driver forcibly abort the Connection instead of
attempting to abort the query?
If the version of MySQL the driver connects to
does not support transactions, still allow calls to
commit(), rollback() and setAutoCommit() (true/
false, defaults to 'false')?
Should the driver retain the Statement reference
in a ResultSet after ResultSet.close() has been
called. This is not JDBC-compliant after JDBC-4.0.
Should the driver issue a rollback() when the
logical connection in a pool is closed?
Enables workarounds for bugs in Sun's JDBC
compliance testsuite version 1.3
Override detection/mapping of timezone. Used
when timezone from server doesn't map to Java
timezone
A comma-delimited list of classes that implement
"com.mysql.jdbc.StatementInterceptor" that
should be placed "in between" query execution to
influence the results. StatementInterceptors are
"chainable", the results returned by the "current"
interceptor will be passed on to the next in in the
chain, from left-to-right order, as specified in this
property.
Used only in older versions of compliance test
Should the driver do strict checking (all primary
keys selected) of updatable result sets (true, false,
defaults to 'true')?
Should the driver treat the datatype TINYINT(1) as
the BIT type (because the server silently converts
BIT -> TINYINT(1) when creating tables)?
If the driver converts TINYINT(1) to a different
type, should it use BOOLEAN instead of BIT
for future compatibility with MySQL-5.0, as
MySQL-5.0 has a BIT type?
Should the driver treat java.util.Date
as a TIMESTAMP for the purposes of
PreparedStatement.setObject()?
Create PreparedStatements for prepareCall()
when required, because UltraDev is broken and
issues a prepareCall() for _all_ statements? (true/
false, defaults to 'false')
Don't set the CLIENT_FOUND_ROWS flag when
connecting to the server (not JDBC-compliant, will
break most applications that rely on "found" rows
vs. "affected rows" for DML statements), but does
cause "correct" update counts from "INSERT ...
ON DUPLICATE KEY UPDATE" statements to be
returned by the server.
Convert between session timezone and GMT
before creating Date and Timestamp instances
2070
false 2.0.13
false 3.1.11
true 3.0.15
false 3.1.7
3.0.2
5.1.1
false 3.0.0
true 3.0.4
true 3.0.16
false 3.1.9
true 5.0.5
false 2.0.3
false 5.1.7
false 3.1.12