Troubleshooting database access
zero.data.
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.
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"
}