Frequently Asked Questions

http://www.jgroups.org/javagroupsnew/docs/faq.html

http://slf4j.org/faq.html

http://www.opensymphony.com/quartz/wikidocs/FAQ.html

Use your logging facility. HA-JDBC generates an ERROR level log message when it automatically deactivates a database. If you use Log4J, configure an SMTP appender for the "net.sf.hajdbc" logger.
If you use java.util.logging, configure an SMTPHandler for the "net.sf.hajdbc" package.

The database element may contain any number of property elements. HA-JDBC will pass these properties through to the Driver.connect(String url, Properties info) method of the underlying JDBC driver.

e.g.

<cluster id="..." balancer="..." default-sync="...">
  <database id="...">
    <driver>org.postgresql.Driver</driver>
    <url>jdbc:postgresql:database</url>
    <property name="ssl">true</property>
    <user>postgres</user>
    <password>XXXX</password>
  </database>
</cluster>

Alternatively, many JDBC drivers accept properties appended directly to the url.

e.g.

<cluster id="..." balancer="..." default-sync="...">
  <database id="...">
    <driver>org.postgresql.Driver</driver>
    <url>jdbc:postgresql:database?ssl=true</url>
    <user>postgres</user>
    <password>XXXX</password>
  </database>
</cluster>

The datasource element may contain any number of property elements. HA-JDBC will pass these properties into the InitialContext(Hashtable env) constructor.

e.g.

<cluster id="..." balancer="..." default-sync="...">
  <datasource id="...">
    <name>jdbc/database</name>
    <property name="java.naming.factory.initial">org.jnp.interfaces.NamingContextFactory</property>
    <property name="java.naming.factory.url.pkgs">org.jboss.naming:org.jnp.interfaces</property>
  </datasource>
</cluster>

Alternatively, these properties may be specified in an jndi.properties application resource file. Details here.

This can occur if your database contains a table with more rows than can be fetched into memory at once. Both the differential and full synchronization strategies have a fetchSize property that control the number of rows that are fetched at a time.

e.g.

<sync id="diff" class="net.sf.hajdbc.sync.DifferentialSynchronizationStrategy">
  <property name="fetchSize">1000</property>
</sync>

Each strategy also has a maxBatchSize property to control the number of statements to execute at a time.

e.g.

<sync id="full" class="net.sf.hajdbc.sync.FullSynchronizationStrategy">
  <property name="maxBatchSize">50</property>
</sync>

Several session replication methods are described in an article posted to TheServerSide.com. Figure 7 illustrates the database persistence approach. When describing the disadvantages of this approach, the article fails to mention that the session database is a single point of failure in this design. HTTP sessions will survive the failure of an application server node, but failure of the session database spells doom for the application.

However, this can easily remedied with redundant session databases using the HA-JDBC driver in distributable mode.

e.g.

For Tomcat, following the configuration instructions for setting up a Persistent Manager using a JDBC store here. Simply use HA-JDBC's driver and url in place of your database's JDBC driver and url for the driverName and connectionURL properties of your store configuration.

Yes, but first you will need to upgrade the JMX implementation used by Tomcat (found in $CATALINA_HOME/bin/jmx.jar). Tomcat 5.0 ships with MX4J 1.1.1 which only implements JMX 1.1. Because HA-JDBC requires JMX 1.2, you will need to upgrade this file to MX4J 2.0 or greater.

HA-JDBC uses the Java preferences API to persist the local database cluster state. The default storage mechanism varies depending on your operating system.

On Unix-like systems, the cluster state will be stored on the file system within the user's home directory:

~/.java/.userPrefs/net/sf/hajdbc/local/prefs.xml

On Windows systems, the cluster state will be stored in the registry:

HKEY_CURRENT_USER\Software\JavaSoft\Prefs\net\sf\hajdbc\local\cluster-name

The username and password set in the configuration file are only used by HA-JDBC when it needs to connect to a database independently of your application. e.g. during synchronization, DatabaseCluster.isAlive() calls, etc. When your application connects to the database, the authentication information specified is passed through to the underlying driver.

The purpose of this authentication pass-through is to retain the flexibility your application had without HA-JDBC to use an appropriate database user (with an appropriate set of permissions) for a given task. Traditionally, applications will use a database user with select/insert/update/delete privileges only. Some application may not need to write information to a database and can use a database user with select privileges only. The database user that is used by HA-JDBC should be more of a root/superuser, with specific abilities to drop and create indexes and foreign keys (used during synchronization).

Since the same password will be passed through to each database, the user used by your application must exist and have the same password on each database in your cluster. The usernames/passwords used by HA-JDBC (as specified in the configuration file), however, do not need to be the same on each database.

Both HA-JDBC and Sequoia attempt to solve the same problem (i.e. eliminating the database as a single point of failure), but have different approaches.