# java.sql.Connection interface

A Derby Connection object is not garbage-collected until all other JDBC objects created from that connection are closed or are themselves garbage-collected.

Once the connection is closed, no further JDBC requests can be made against objects created from the connection. Do not explicitly close the Connection object until you no longer need it for executing statements.

The Connection interface extends AutoCloseable in JDK 7 and after. If you declare a connection in a try-with-resources statement and there is an error that the code does not catch, the JRE will attempt to close the connection automatically.

Note that a transaction-severity or higher exception causes Derby to abort an in-flight transaction. But a statement-severity exception does NOT roll back the transaction. Also note that Derby throws an exception if an attempt is made to close a connection with an in-flight transaction. Suppose now that a Connection is declared in a try-with-resources statement, a transaction is in-flight, and an unhandled statement-severity error occurs inside the try-with-resources block. In this situation, Derby will raise a follow-on exception as the JRE exits the try-with-resources block. (For details on error severity levels, see derby.stream.error.logSeverityLevel.)

It is therefore always best to catch errors inside the try-with-resources block and to either roll back or commit, as appropriate, to ensure that there is no pending transaction when leaving the try-with-resources block. This action also improves application portability, since DBMSs differ in their semantics when trying to close a connection with a pending transaction.

The following table describes features of Connection methods that are specific to Derby.

Table 1. Implementation notes on Connection methods
Returns | Signature | Implementation Notes
--- | --- | ---
PreparedStatement | prepareStatement(String sql, int [] columnIndexes) | Every column index in the array must correlate to an auto-increment column within the target table of the INSERT.
PreparedStatement | prepareStatement(String sql, String [] columnNames) | Every column name in the array must designate an auto-increment column within the target table of the INSERT.

See Autogenerated keys for details on the use of the two forms of the Connection.prepareStatement method shown in this table.

- java.sql.Connection.setTransactionIsolation method
  The transaction isolation levels java.sql.Connection.TRANSACTION_SERIALIZABLE, java.sql.Connection.TRANSACTION_REPEATABLE_READ, java.sql.Connection.TRANSACTION_READ_COMMITTED, and java.sql.Connection.TRANSACTION_READ_UNCOMMITTED are available from a Derby database.
- java.sql.Connection.setReadOnly method
  The java.sql.Connection.setReadOnly method is supported.
- java.sql.Connection.isReadOnly method
  If you connect to a read-only database, the appropriate isReadOnly DatabaseMetaData value is returned.
- Connection functionality not supported
  Derby does not use catalog names. In addition, the following optional methods raise "Feature not supported" exceptions.

Parent topic: JDBC reference
Related reference
java.sql.Driver interface
java.sql.DriverManager.getConnection method
java.sql.DatabaseMetaData interface
java.sql.Statement interface
java.sql.CallableStatement interface
java.sql.PreparedStatement interface
java.sql.ResultSet interface
java.sql.ResultSetMetaData interface
java.sql.SQLException class
java.sql.SQLWarning class
java.sql.SQLXML interface
java.sql.Savepoint interface
Mapping of java.sql.Types to SQL types
Features supported on JDBC 4.1 and above
JDBC 4.2-only features
JDBC escape syntax