The parameter required by the DriverManager.getConnection function is the JDBC connection string. The JDBC connection string identifies which computer the database server is running on. The string also contains other information required to connect to the server.
The syntax of the JDBC URL (connection string) for the solidDB® server is:
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 connection lifecycle in a very accurate way, otherwise there may be conflicts between concurrent users and applications trying to access the database. For details and instructions, see Code examples.
Note The solidDB® JDBC Driver only supports a connection for administration options with no queries allowed. For this type of connection, set the 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 be in either autocommit or non-autocommit mode.
▪When not in autocommit mode, each transaction needs to be explicitly committed before the modifications it made can be seen by other database connections.
▪The autocommit state can be monitored by Connection.getAutoCommit() method.
▪The state can be set by Connection.setAutoCommit(). The default setting for autocommit state is true.
▪If autocommit mode is off, then the transactions can be committed in two ways.
– calling the Connection.commit() method, or
– 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 specified in JDBC interfaces may throw an instance of SQLException. As these errors may appear in the normal application workflow (representing concurrency conflicts, for instance) your code should be tolerant to such errors. Basically, you must not leave your connections in any other state than “closed” regardless of the result of your code’s execution. This approach allows avoiding situations where all available connections remain open due to unhandled exceptions.
You can get an exception’s error code by calling e.getErrorCode(). For listings of solidDB® error codes, see the Appendix Error codes in solidDB® Administrator Guide.
The following code example shows a correct way of handling errors coming 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; } }