1. The datasource participant

1. The datasource participant
Prev	Chapter 7. Adding database support	Next

First of all, we need a datasources participant in the repository, and we'll also write a small configuration file for that participant. After editing rep/participants.xml, it looks like this:

Example 7.1. Adding a data source participant

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rep SYSTEM "/dtd/rep.dtd">
    
<rep>
  <participant param="rep/config.xml">ParticipantConfig</participant>
      
  <!-- Add a data sources participant: -->
  <participant param="rep/datasources.xml">ParticipantDatasources</participant>
      
  <participant param="sites/friends.xml">ParticipantSite</participant>
</rep>

Then we write the data sources definition file specified above, rep/datasources.xml, to set up two different data sources:

Example 7.2. Data source definition

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE datasources SYSTEM "/dtd/datasources.dtd">
         
<datasources>

  <datasource name="postgresql">
    <driver>org.postgresql.Driver</driver>
    <url>jdbc:postgresql://localhost:5432/rife</url>
    <user>rife</user>
    <password>rife</password>
    <poolsize>5</poolsize>
  </datasource>
      
  <datasource name="mysql">
    <driver>com.mysql.jdbc.Driver</driver>
    <url>jdbc:mysql://localhost:3306/rife</url>
    <user>rife</user>
    <password>rife</password>
    <poolsize>5</poolsize>
  </datasource>

</datasources>

The reason we use two different data sources (one for PostgreSQL and one for MySQL) is to make the application more useful without the need to change the code just because one or the other is not available. A good example of this is when the configuration of the developer machine is different than the one running the application. The attentive reader probably recalls configuration selectors from the previous chapter, and points out that a host name selector would be excellent in that case!

Another benefit is that if the code works equally well with different databases, the chances of it being usable for other people or in other projects increase a lot. Code reuse is always a good thing, and can save time by not forcing people to re-invent the wheel time after time.

RIFE comes with built-in support for the PostgreSQL, MySQL and Oracle databases. Custom drivers can be written if another database is used, but that is outside the scope of this document.

1.1. Datasource parameters

There are a few parameters to set for each datasource:

1.1.1. Username and password

The user and password tags set the username and password to use for connecting to the database, and should hopefully be fairly self-explanatory.

1.1.2. Database driver

The driver tag specifies which database driver to use, and is one of org.postgresql.Driver, com.mysql.jdbc.Driver and oracle.jdbc.driver.OracleDriver, if one of the included drivers is used.

1.1.3. URL

The url tag specifies the location of the database. The first part, "jdbc" is the main protocol, "postgresql" or "mysql" is the sub-protocol, followed by the host name "localhost" and port number to connect to. The last part, "rife", is the name of the database. Of course, these are all just example values that you might have to modify according to your actual setup.

1.1.4. Connection pool

Since connecting to the database can be time consuming, RIFE can keep a pool of open database connections. This can increase the performance, especially for web sites that generate a lot of traffic. The poolsize tag controls the number of connections in the pool, where 0 means that no pool is used. We'll go for a moderate value of 5 here.