Multiple DLXS Releases

Introduction

How to install and configure two DLXS releases

How to point two different DLXS releases at the same data

Introduction

There are times when you might want to have two different releases of DLXS Middleware running at the same time.

You might want to keep a past release running in production mode but still have the ability to install, configure and migrate your local changes to a new release version.
And given installations of two different releases of DLXS Middleware:

You may or may not want to have both releases pointing to the same indexed data.
You will almost certainly need different versions of the DLXS database for each DLXS release.

Whether you need multiple installations will depend a lot on how you manage you DLXS site locally. These are all considerations in how to install and configure multiple releases of DLXS.

How to install and configure two DLXS releases

Two DLXSROOT values and two databases

The basic idea is to install the new release into a separate directory not within the directory of the earlier release. When the installer program (Installer.pl) prompts you for your DLXSROOT, give it the new directory you want to create to hold the new DLXS release.

When the installer prompts you for the database type your answer will depend on whether you want to use the CSV database files that live in the install tree for each release or MySQL.

Choosing CSV probably means you'll be copying the CSV files from the old release to the new release tree and running the upgrade utilities on them. (Details in Database Migration).
Choosing MySQL probably means you'll be creating another database under your MySQL server but with a different name, e.g. dlxs11. (Details in Database Migration). Just remember to answer the installer with the new database name you're planning to create during migration.

It is not necessary to have separate CSV session file locations (e.g./tmp/sessions, /tmp/sessionslock) or a separate MySQL sessions table for each of the two different DLXS releases. Note that sessions created by different releases of DLXS are not compatible. This is not generally a problem if you expire sessions regularly.

Separate Virtual Hosts

Next, configure another virtual host under your web server and set DLXSROOT for that virtual host to point to the directory containing the new release. Recall what a virtual host configuration looks like.

For example, suppose you have DLXS release 10 installed under /usr/local/dlxs10 and you choose to install DLXS release 11 under /usr/local/dlxs11. You would have the release 10 virtual host (already) configured with:

SetEnv DLXSROOT /usr/local/dlxs10 DocumentRoot /usr/local/dlxs10/web ScriptAlias /cgi/ /usr/local/dlxs10/cgi/

and you would configure the release 11 virtual host with:

SetEnv DLXSROOT /usr/local/dlxs11 DocumentRoot /usr/local/dlxs11/web ScriptAlias /cgi/ /usr/local/dlxs11/cgi/

So for release 10 your URL might be:    diglib10.somewhere.edu/cgi/t/text/text-idx

and your release 11 virtual host might be:

    diglib11.somewhere.edu/cgi/t/text/text-idx

where each URL would run middleware from a different install tree, i.e. a different DLXSROOT.

How to point two different DLXS releases at the same data

Data (SGML/XML, image files) and XPAT indexes occupy a lot of disk space. DLXS middleware recognizes the DLXSDATAROOT environment variable so that a given release can point to the data/index/image directories (under obj, idx,img)outside of its own install tree.

If the virtual host for a given DLXS release defines DLXSDATAROOT, that value is used as the path prefix for the obj, idx,img directories. If not, the DLXSROOT value is used for the path prefix.

In the earlier example, in the virtual host for release 11, you could set DLXSDATAROOT to /usr/local/dlxs10 to have release 11 read data from the release 10 install tree.

This scenario requires that the release 10 data be forward compatible with release 11. (More on this when we talk about data preparation for TextClass). If forward compatibility is a problem, the data could be moved to the release 11 tree and pointed to from the release 10 middleware. Then the data could be migrated gradually to work with 11 in a manner that was backward compatible with 10.

There are other possibilities for using DLXSDATAROOT. For example, you could configure more than one virtual host for the same release. One virtual host could use DLXSDATAROOT to point outside its tree while another points at data within its own tree etc.

Another scenario might be to have your data in a single location entirely outside all install trees and use DLXSDATAROOT in every virtual host to point at that single location.