Derby in a Server Framework

In a sense, Derby is always an embedded product. You can embed it in an application where users access the database from a single JVM or in a server framework-an application that allows users from different JVMs to connect to Derby simultaneously. When Derby is embedded in an application, the local JDBC driver calls the local Derby database. When Derby is embedded in a server framework, the server framework's connectivity software provides data to multiple client JDBC applications over a network or the Internet.

For local or remote multi-user (multiple users accessing from different JVMs) connectivity, use the Derby Network Server. If you require features other than those included in Network Server, you can embed the basic Derby product in another server framework.

There are many ways you can embed Derby in a server framework:

• Use the Network Server.

  The easiest way to provide connectivity to multiple users accessing Derby databases from different JVMs. The Derby Network Server provides this kind of connectivity to Derby databases within a single system or over a network.

• Purchase another server framework.

  You can use Derby within many server frameworks, such as the IBM^(R) WebSphere Application Server.

• Write your own framework.

Derby's flexibility allows other configurations as well. For example, rather than embedding Derby in a server that communicates with a client using JDBC, you can embed Derby within a servlet in a Web server that communicates with a browser using HTTP.

The basic Derby product contains some features that are useful for developing multi-user applications. These features include:

• Row-Level Locking
• Multiple Concurrency Levels
• Multi-Connection and Multi-Threading
• Administrative Tools

To support multi-user access, Derby utilizes row-level locking. Derby can be configured to use table-level locking In environments with few concurrent transactions (for example: a read-only database) . Table-level locking is preferable if there are few or no writes to the server, while row-level locking is essential for good performance if many clients write to the server concurrently. The Derby optimizer tunes lock choice for queries automatically.

Derby supports SERIALIZABLE (RR), REPEATABLE READ (RS), READ COMMITTED (CS), and READ UNCOMMITTED (UR) isolation levels. CS (the default isolation level) provides the best balance between concurrency and consistency in multiple-client environments. RS provides less consistency than RR but allows more concurrency. RR provides greatest consistency. UR provides maximum concurrency, if uncommitted values are allowed in the query. It is typically used if approximate results are acceptable. See "Types and Scope of Locks in Derby Systems" in the Derby Developer's Guide for more information.

Derby allows multiple simultaneous connections to a database, even in embedded mode. Derby is also fully multi-threaded, and you can have multiple threads active at the same time. However, JDBC semantics impose some limitations on multi-threading. See the Derby Developer's Guide for more information.

Derby provides some tools and features to assist database administrators. These tools are:

• Consistency checker
• On-line backup
• The ability to put a database's log on a separate device

These tools and features are discussed in part two of this book. See the chapters in that section for more information.

The Derby Network Server provides multi-user connectivity to Derby databases within a single system or over a network. The Network Server receives and replies to queries from clients using standard Distributed Relational Database Architecture (DRDA) protocol. One method databases may be accessed through the Derby Network Server is by using the IBM JDBC driver, the DB2 JDBC Universal Driver. This driver is available for free download from IBM developerWorks. Other clients could be written to access the database through the Derby Network Server, however none are included with Derby at this time.

The network server is a solution for multiple JVMs connecting to the database, unlike the embedded scenario where one JVM is all that runs as part of the system. When Derby is embedded in a single-JVM application, the embedded JDBC driver calls the local Derby. When Derby is embedded in a server framework, the server framework's connectivity software provides data to multiple client JDBC applications over a network or the Internet.

To run the Derby Network Server, you will need to install the following files:

On the server side (included with Derby):

• derby.jar
• derbynet.jar

On the client side (not included with Derby, but may be downloaded for no charge from IBM developerWorks).

• db2jcc.jar
• db2jcc_license_c.jar

There are several ways to manage the Derby Network Server:

• through the command line
• using .bat and .ksh scripts
• through the servlet interface
• with your own Java program (written using the Network Server API)
• by setting Network Server properties

Using the Network Server with preexisting Derby applications explains how to change existing Java applications that currently run against Derby in embedded mode to run against the Derby Network Server.

"Managing the Derby Network Server" explains how to manage the Network Server via the command line, including starting and stopping it.

"Derby Network Server Advanced Topics" contains advanced topics for Derby Network Server users.

Because of the differences in JDBC drivers that are used, you might encounter differences in functionality when running Derby in the Network Server framework rather than running it embedded in a user application. Refer to Using the Network Server with preexisting Derby applications here for a complete list of the differences between embedded and Network Server configurations.

Since Derby is written in Java, you have great flexibility in configuring your deployment. For example, you can run Derby, the JDBC server framework, and another application in the same JVM as a single process.

In one thread, the embedding application boots the local JDBC driver for its own access.

/* loading the client driver boots the client driver only*/
Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
Connection conn = DriverManager.getConnection(
    "jdbc:derby:sample");
 
 

In another thread, the same application boots the server framework to allow remote access. Booting the server framework from within the application allows both the server and the application to run in the same JVM.

Network Server can be started in another thread automatically when Derby boots by setting the derby.drda.startNetworkServer property (see Setting Network Server Properties) or it can be started using a program:

import org.apache.derby.drda.NetworkServerControl;
import java.net.InetAddress;
NetworkServerControl server = new NetworkServerControl
    (InetAddress.getByName("localhost"),1527);
server.start(null);

The program starting Network Server can access the database with either the embedded driver or the IBM JDBC Universal Driver. The server framework's attempt to boot the local JDBC driver is ignored because it has already been booted within the application's JVM. The server framework simply accesses the instance of Derby already booted. There is no conflict between the application and the server framework.

The remote client can then connect via the client driver:

String nsURL="jdbc:derby:net://localhost:1527/
sample:retrieveMessagesFromServerOnGetMessage=true;"; 
java.util.Properties props = new java.util.Properties();
props.put("user","usr");
props.put("password","pwd");
 
Class.forName("com.ibm.db2.jcc.DB2Driver").newInstance();
Connection conn = DriverManager.getConnection(nsURL, props);
 
/*interact with Derby*/
Statement s = conn.createStatement();
 
ResultSet rs = s.executeQuery(
"SELECT * FROM HotelBookings");