Troubleshooting database access

Configuration tips and workarounds if you run into problems using zero.data.
The following contains tips in configuring connection to databases and resolving issues with zero.data. Although this document is not comprehensive and you should rely primarily on your database vendor's official documentation.

When debugging an issue with connecting to databases, often using a database connection trace file is most helpful. In it is contained detailed interactions with the database and can help understand what might be going wrong with your environment.

Most DataSource implementations conveniently allow the configuration of a trace file. Each vendor's driver documentation will contain more complete examples on trace file configuration. However, most drivers use the traceFile property as follows:

/config/db/mydb = {
    "traceFile" : "${appname}/logs/db.txt"
}

In this example, ${appname} should be replaced by your application name from the application's ivy.xml. For instance, if your application is named myapp, you would use ${myapp}. The parsing of the zero.config file will expand to the correct folder location.

The traceFile property can also be a hardcoded value. For instance, C:/db/logs/db-trace. But using the variable allows for better portability of your application.

IBM® DB2®

Obtaining DB2® drivers

Make sure you use the most recent drivers for your DB2® version. As of sMash version 1.1.0.1, when using zero.data with DB2®, you must use the DB2 JCC driver version 3.53 or later.

If you do not already have a DB2 license, there is a "community" version, DB2® Express-C, that is available with a free license to develop, deploy, and distribute.

Configuration

The DB2SimpleDataSource requires several properties in order to successfully connect. The following example show basic usage required to connect to to a DB2® database:

/config/db/mydb = {
    "class" : "com.ibm.db2.jcc.DB2SimpleDataSource",
    "driverType" : 4,
    "serverName" : "localhost",
    "portNumber" : 50000,
    "databaseName" : "MYDBNAME",
    "user" : "someuser",
    "password" : "secretpassword"
}

For complete details about the valid properties for DB2® DataSource implementations, see the DB2® documentation. The default driverType value is 2, which is the native CLI wrapper. Unless you have your jars and dlls all set up correctly, it can be a pain to debug exactly why you aren't getting a Connection. By setting to 4, the pure Java driver, you'll have better success.

For more information about selecting the appropriate DB2® DataSource implementation, see the DB2® documentation. If you face any issues, look below for workarounds or post to the forum.

Throughput is slow on DB2®

By default, DB2® activates and deactivates a database on demand when connections are made. Thus, with short-lived connections, as IBM® WebSphere® sMash, under some situations, you may see a significant decrease in performance and throughput because the database is being activated and deactivated upon each connection open and close.

In testing, performance increase was discovered by issuing a CONNECT TO. This caused a connection to persist for the lifetime of the Command Line Processor's session, for when the DB2® user logged off, decreased performance resumed.

Rather, database administrators can use ACTIVATE DATABASE to start up specific databases. This eliminates any application time spent on database initialization.

Consult the DB2® documentation on ACTIVATE DATABASE for more usage information. Specifically, look at the "Usage notes" on the behavior of this command when the database server is stopped and restarted.

Activating databases on OS startup

You might find it useful, if your environment requires it, to activate DB2® databases when the operating system starts. To do this, you can create a startup script that executes DB2® Command Line Processor commands.

Example Not Supported The following example only illustrates a solution or workaround and is not officially supported.

For instance, the following System V-style startup script has been successfully tested on Ubuntu 7.10:

#!/bin/bash
###################################################
####Startup script for activating DB2 databases ###
###################################################

USER=db2inst1
case "$1" in
start)
/bin/su - $USER -c "db2 activate db emp_db"
;;
stop)
/bin/su - $USER -c "db2 deactivate db emp_db"
;;
restart|force-reload)
/bin/su - $USER -c "db2 deactivate db emp_db"
/bin/su - $USER -c "db2 activate db emp_db"
;;
*)
exit 1
;;
esac

exit 0

Replace the database name with your own. If your DB2® user is different, replace the USER value. Save this script in a file under the /etc/init.d/ directory. Let's say you called it dbactivate. Issue the following commands to have the script run at system start up:

$ chmod +x /etc/init.d/dbactivate
$ update-rc.d dbactivate defaults

You can issue start, stop and restart commands:

$ /etc/init.d/dbactivate start
$ /etc/init.d/dbactivate stop
$ /etc/init.d/dbactivate restart

Apache Derby

Obtaining Derby drivers

Derby is a pure Java database and is contained in IBM WebSphere sMash. The embedded drivers are contained in the core Derby jar file. To use Derby in embedded mode, declare an application dependency on derby as follows:

<dependency name="derby" org="org.apache.derby" rev="[10.3.0.0, 10.4.0.0["/>

To use Derby in network mode, declare an application dependency on derbyclient as follows:

<dependency name="derbyclient" org="org.apache.derby" rev="[10.3.0.0, 10.4.0.0["/>

Configuration

The configuration for embedded and network Derby differs slightly. Each is detailed below.

Embedded Mode

To connect to a Derby database in embedded mode, only the EmbeddedDataSource only needs to know the folder path to where the database files are:

/config/db/mydb = {
    "class" : "org.apache.derby.jdbc.EmbeddedDataSource",
    "databaseName" : "db/customer"
}

In this example, the EmbeddedDataSource will start the Derby database engine in the same Java process. If the databaseName does not point to a valid Derby database folder, an exception is thrown.

Sometimes it is convenient to have Derby automatically create the database file system upon first connection using the createDatabase set to create. However, when using this option, Derby will blindly create new databases. Thus, when this option is used with relative paths, it can get very confusing when ables don't exist because the working directory has changed and the database 'successfully' connects to a newly created database.

You can use createDatabase as follows:

/config/db/mydb = {
    "class" : "org.apache.derby.jdbc.EmbeddedDataSource",
    "databaseName" : "db/MYDBNAME",
    "createDatabase" : "create"
}

Network Mode

In network mode, Derby's ClientDataSource connects to a running Derby instance over a network connection. Multiple databases can be served from one hosting Java process. Just as in client mode databaseName is the folder path:

/config/db/mydb = {
    "class" : "org.apache.derby.jdbc.ClientDataSource",
    "databaseName" : "db/MYDBNAME",
    "serverName" : "localhost",
    "portNumber" : 1527,
    "user" : "someuser",
    "password" : "secretpassword"
}

Because network mode connects over the network, several more connection properties are available, as shown in the previous example.

Issues

Derby has two 'modes': Embedded and Network. Derby always runs in a JVM, it just depends on where.

Embedded Mode

As you can probably guess, embedded mode runs in the same JVM as IBM® WebSphere® sMash. This is convenient, but has some issues. For instance, Derby locks the file system where data is persisted to disk. As such, if WebSphere sMash is running and has established a connection in Embedded mode, the Embedded Derby engine is running and will prevent other Derby tools from talking to the database. When in Embedded mode, the Derby databaseName property is the file system path to your database relative to your WebSphere sMash application. So, db/mydb would be under ` %approot%/db/mydb.

Network Mode

Running in Network mode requires one more step, just like every other database 'server', but Network mode requires starting a Java process. This is possible with the Derby Eclipse Plugin or from the command line. The Eclipse Plugin makes it possible to start the network process by right clicking on a project. When this is done, the Derby databaseName property is the same as Embedded mode, relative to the application root. However, when the command line option is used (%derby_home%/frameworks/NetworkServer/bin/startNetworkServer.bat), beware that the databaseName property is relative to the working directory (i.e. where you execute startNetworkServer.bat from). To simplify things, it might be wise to put the directory where this batch file lives on the system path and execute it from the application root.

Configure the Derby Trace File

Derby configures its trace file through Java System Properties. This can be accomplished by setting the properties on the command line. Derby documentation has more details. The trace file can also be set on both client and embedded DataSource implementations by setting the following property in zero.config:

/config/db/mydb = {
    "class" : "org.apache.derby.jdbc.ClientDataSource",
    ...
    "traceFile" : "${appname}/logs/db.txt"
}

MySQL

Obtaining MySQL drivers

MySQL JDBC drivers, Connector/J 5.0, can be downloaded from MySQL's website under its own terms and license. For complete information about configuring and tuning connection properties, consult the MySQL DataSource Documentation

Configuration

The MysqlDataSource requires several properties in order to successfully connect. The following example show basic usage required to connec to to a MySQL database:

/config/db/mydb = {
    "class" : "com.mysql.jdbc.jdbc2.optional.MysqlDataSource",
    "serverName" : "db.example.org",
    "portNumber" : 3306,
    "databaseName" : "MYDBNAME",
    "user" : "someuser",
    "password" : "secretpasssword"
}

Oracle

Obtaining Oracle drivers

Oracle JDBC drivers can be downloaded from Oracle's website under its own terms and license. For complete information about configuring and tuning connection properties, consult the Oracle's documentation.

Configuration

The OracleDataSource requires several properties in order to successfully connect. The following example show basic usage required to connec to to an Oracle database:

/config/db/mydb = {
    "class" : "oracle.jdbc.pool.OracleDataSource",
    "serverName" : "db.example.org",
    "portNumber" : 1521,
    "driverType" : "thin",
    "databaseName" : "MYDBNAME",
    "user" : "someuser",
    "password" : "secretpassword"
}

Performance issues making connections

Oracle's oracle.jdbc.pool.OracleDataSource implementation of the javax.sql.DataSource interface contains connection pooling built right in. Thus, they assume everybody will use connection pooling, which WebSphere sMash does not provide out of the box. Because of this assumption, OracleDataSource justifies expensive methods calls to Java's cryptography library. This can result in long connections to the database as compared to other vendors.

The behavior of zero.data.Manager's methods is to obtain a connection, use it, and call the close method (unless methods are executed under the inTransaction() method or a java.sql.Connection is passed into the zero.data.Manager constructor).

Microsoft® SQL Server®

Obtaining SQL Server® drivers

JDBC drivers can be obtained from the Microsoft® website under its own terms and license. For complete information about configuring and tuning connection properties, consult the SQL Server® documentation.

Configuration

The SQLServerDataSource requires several properties in order to successfully connect. The following example show basic usage required to connec to to an Oracle database:

/config/db/mydb = {
    "class" : "com.microsoft.sqlserver.jdbc.SQLServerDataSource",
    "serverName" : "db.example.org",
    "portNumber" : 1433,
    "databaseName" : "MYDBNAME",
    "user" : "someuser",
    "password" : "secretpassword"
}

Version 1.1.31300