Write access, principles
Connecting an application to a database by establishing a connection between client and database server:
-
Protocol connecting database client and server.
-
Vendor dependent implementations.
So JDBC™ is just one among a whole bunch of protocol implementations connecting database servers and applications. Consequently JDBC™ is expected to appear in the lower layer of multi-tier applications. We take a three-tier application as a starting point:
We may add an additional layer. Web applications are typically being build on top of an application server (WebSphere, Glassfish, Jboss,...) providing additional services:
Opening a connection to a database server requires:
Items 1 - 4 will be encapsulated into a so called JDBC™ URL. We consider a typical example corresponding to the previous parameter list:
https://www.ietf.org/rfc/rfc2396.txt
:
absoluteURI = scheme ":" ( hier_part | opaque_part )
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
...
-
http://www.hdm-stuttgart.de/aaa
-
http://someserver.com:8080/someResource
Non-standard port 8080
-
ftp://mirror.mi.hdm-stuttgart.de/Firmen
Database | JDBC™ URI |
---|---|
PostgreSQL | jdbc:postgresql://<HOST>:<PORT>/[database] |
MySQL | jdbc:mysql://[host][:port]/[database][?p1=v1]... |
Oracle | jdbc:oracle:thin:[user/password]@[host][:port]:SID |
DB2 | jdbc:db2://<HOST>:<PORT>/[database] |
Derby | jdbc:derby://[host][:port]/[database] |
MS. SQL S. | jdbc:sqlserver://host[:port];user=xxx;password=xyz |
Sybase | jdbc:sybase:Tds:<HOST>:<PORT>/[database] |
|
|
>grep postgresql /etc/services postgresql 5432/tcp postgres # PostgreSQL Database postgresql 5432/udp postgres
Writing JDBC™ based applications follows a simple scheme:
From a programmer's point of view the java.sql.DriverManager
is a bootstrapping object: Other objects like Connection
instances are being created from this central and unique
object.
DriverManager
:
Bootstrapping connections -
Bootstrapping object.
-
java.sql.DriverManager
shipped with JRE™. -
Provides instances of
java.sql.Connection
.
-
Interface
MySQLConnection
extends
java.sql.Connection
-
Class
ConnectionImpl
implementsMySQLConnection
<groupId>postgresql</groupId> <artifactId>postgresql</artifactId> <version>9.1-901-1.jdbc4</version>
<groupId>com.oracle</groupId> <!-- requires access credentials --> <artifactId>ojdbc7</artifactId> <version>12.1.0</version>
Figure 849, “JDBC™ architecture ” does not show
details about the relations between
java.sql.Connection
,
java.sql.Statement
and
java.sql.ResultSet
objects. We start by giving
a rough description of these three interfaces' tasks and
responsibilities:
java.sql.Connection
-
-
Holding a permanent database server connection .
-
Stateful protocol.
-
Per connection properties: Isolation level, auto commit,...
-
java.sql.Statement
-
Two distinct operation classes:
executeUpdate()
-
INSERT
,UPDATE
,DELETE
: Integer return code executeQuery()
-
SELECT
: Returningjava.sql.ResultSet
, see the section called “Read Access”.
From JDBC and Multithreading:
“Because all Oracle JDBC API methods are synchronized, if two threads try to use the connection object simultaneously, then one will be forced to wait until the other one finishes its use.”
Consequence:
-
Use one
java.sql.Connection
per thread. -
Use connection pooling e.g. c3po.
try (final Connection conn =
C3P0DataSource.getInstance().getConnection()) {
final PreparedStatement pstmt = conn.create...;
...
pstmt.executeUpdate();
// Auto close connection, back to pool.
} catch (SQLException e) {
e.printStackTrace();
}