The parameter required by the DriverManager.getConnection() function is the JDBC connection string. The JDBC connection string identifies the computer that is running the database server. The string also contains other information required to connect to the server.
The JDBC URL (connection string) for the solidDB server has the following syntax:
For example, the following connect string attempts to connect to the server in machine fb9 that is listening to the TCP protocol at port 1314:
"jdbc:solid://fb9:1314/dba/dba"
The application can establish multiple connections to the database by using multiple connection objects. You should manage the connection lifecycle carefully, otherwise there might be conflicts between concurrent users and applications trying to access the database. For details and instructions, see solidDB JDBC driver samples.
Note The solidDB JDBC driver supports an administration-only connection where no queries are allowed. For this type of connection, set java.util.Properties name ADMIN_USER to true. After it is set to true and a connection is established, only ADMIN commands are allowed.
Transactions and autocommit mode
As the JDBC specification defines, a connection to the solidDB database can have autocommit mode set to true or to false.
▪ The autocommit mode can be set by the Connection.setAutoCommit() method. The default setting for autocommit mode is true.
▪ The autocommit mode can be monitored by the Connection.getAutoCommit() method.
▪ When autocommit mode is set to false, each transaction must be explicitly committed before the modifications made by the transaction can be seen by other database connections. Transactions can be committed in the following ways:
– by calling the Connection.commit() method,
– by executing a statement for SQL 'COMMIT WORK'.
Handling database errors
Database errors in JDBC are handled and managed by the exception mechanism. Most of the methods that are specified in JDBC interfaces can throw an instance of SQLException. As these errors might appear in the normal application workflow (representing concurrency conflicts, for instance) your code should tolerate such errors. Basically, you must not leave your connections in any other state than "closed" regardless of the result of your code execution. This approach avoids situations where all available connections remain open due to unhandled exceptions.
You can get the error code for an exception by calling e.getErrorCode(). For listings of solidDB error codes, see Error codes.
The following code example shows a correct way of handling errors that come from the database:
Public void listTablesExample() { try { Class.forName("solid.jdbc.SolidDriver"); } catch (ClassNotFoundException e) { System.err.println("Solid JDBC driver is not registered in the classpath"); return; //exit from the method } Connection conn = null; Statement stmt = null; ResultSet rs = null; try { conn = DriverManager.getConnection("jdbc:solid:// localhost:1313", "dba", "dba"); stmt = conn.createStatement(); rs = stmt.executeQuery("SELECT * FROM tables"); while (rs.next()) { System.out.println(rs.getObject(0)); //printing out results } } catch (SQLException e) { e.printStackTrace(); } finally { /* It's a good idea to release resources in a finally{} block in reverse-order of their creation if they are no-longer needed */ if (rs != null) { try { rs.close(); } catch (SQLException sqlEx) { // ignore rs = null; } } if (stmt != null) { try { stmt.close(); } catch (SQLException sqlEx) { // ignore stmt = null; } } } if (conn != null) try { conn.close(); } catch (SQLException e) { e.printStackTrace(); } finally { conn = null; } }