Multiple DLXS Releases
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
- 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
- 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
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
ScriptAlias /cgi/ /usr/local/dlxs10/cgi/
and you would configure the release 11 virtual host with:
SetEnv DLXSROOT /usr/local/dlxs11
So for release 10 your URL might be:
ScriptAlias /cgi/ /usr/local/dlxs11/cgi/
and your release 11 virtual host might be:
where each URL would run middleware from a different install tree, i.e. a
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.