You might want to have two different releases of DLXS Middleware running at the same time. For example, to keep a past release running in production while installing, configuring and migrating your local UI or code changes to a new release.
Given these two installations, you may or may not want to have both releases pointing to the same image files and indexed XML data.
Suppose you already have a pervious DLXS release and database installed.
CAVEAT: The session ID is stored in a cookie. Search History and Bookbag are stored in the session so crossing between different releases will drop the Search History and Bookbag holdings because the session ID is a handle to a record in the database and different releases have different databses. Similarly, portfolios are stored in the database. A portfolio created in one release will not be accessible if the user crosses to a different release.
Data (SGML/XML, image files) and XPAT indexes occupy a lot of disk space. DLXS middleware recognizes the DLXSDATAROOT environment variable. A given release can point to the data/index/image directories (under obj, idx and 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 and img directories. If DLXSDATAROOT is not defined, the DLXSROOT value is used for the path prefix.
For example, in the virtual host for release 13, you could set DLXSDATAROOT to /usr/local/dlxs12 to have release 13 read data from the release 12 install tree.
Another scenario might be to have your data in a single location entirely outside any install trees and use DLXSDATAROOT in every virtual host to point at that single location.