Configures the storage back-end.

Default settings for the serializer (external data representation).

Controls the indexing process.

Configuration options related to XUpdate processing.

This attribute selects a database system type. Since relational database back-ends are no longer supported by the current release of eXist, only "native" and "native_cluster" are available.

This attribute specifies the directory where the native back-end will keep its database files, and so it is necessary that this directory exists. If a relative path is specified, it will be based on the root directory as defined in the exist.home system property. If this data directory does not have write permissions (see User Authentication and Access Control), eXist will internally switch to read-only mode such that any attempt to change the database will throw an exception.

This attribute sets the maximum amount of main memory used by all page buffers (i.e. assuming all page buffers are at full capacity). The database uses this parameter to calculate the maximum size of each internal cache. You can increase this value if your system allows for greater memory use.

While indexing documents, eXist will reserve the amount of memory specified in cacheSize - even if not all caches are filled - and will not use it for temporary data.

The cacheSize should not be more than half of the size of the JVM heap size (set by the JVM -Xmx parameter). If the JVM heap is less than 512 megabyte, the cacheSize should even be smaller, e.g. 1/3.

Determines the size of the collection cache, which is a separate caching space. Usually this setting does not need to be changed unless you really have more than a few thousand collections in the db. Increase it carefully, maybe up to 128M.

This specifies the number of bytes used for internal data and B-tree pages. This should be equal to or a multiple of the page size used by the filesystem (usually a multiple of 4096).

Size of the temporary buffer used by eXist for caching index data while indexing a document. If set to -1, eXist will use the entire free memory to buffer index entries and will flush the cache once the memory is full.

If set to a value > 0, the buffer will be fixed to the given size. The specified number corresponds to the number of nodes the buffer can hold, in thousands. Usually, a good default could be nodesBuffer="1000".

The default setting, nodesBuffer="-1", can be problematic if you frequently need to store large documents in a multi-user environment. In this case, the index operation may consume most of the memory resources, which means that concurrent threads will be slowed down or may even come to a halt.

These options specify the minimum and maximum size of the connection pool. This pool restricts the number of parallel (basic) operations that can be executed by the database. Settings should be somewhere between 1 and 20. (Please note that this has nothing to do with the HTTP and XMLRPC server settings - these servers have their own connection pools.)

This option defines how often the database will flush its internal buffers to disk (in milliseconds). The sync-thread will interrupt normal database operation after the specified time and write all dirty pages to disk. It also writes a checkpoint to the transaction log. In case of a database crash, only transactions which started after the last checkpoint have to be redone or rolled back. The sync-period should thus not be set too long.

This option specifies the maximum amount of time (in milliseconds) that the database will allow for any running processes to complete upon database shutdown. After that, eXist will try to kill the remaining processes.

If wait-before-shutdown is set to a positive number, eXist will stop the db after the specified timeout, even if there were still running database operations. In this case, no checkpoint will be written to the transaction log. If there were any open transactions, eXist will trigger a recovery run after restart.

If wait-before-shutdown is set to -1, eXist will not shut down before all active database operations returned. This is a safe setting, but it may require a manual intervention to stop the jvm.

If this attribute is set to yes, automatic recovery is enabled.

This attributes sets the maximum allowed size of the journal file. Once the journal reaches this limit, a checkpoint will be triggered and the journal will be cleaned. However, the database waits for running transactions to return before processing this checkpoint. In the event one of these transactions writes a lot of data to the journal file, the file will grow until the transaction has completed. Hence, the size limit is not enforced in all cases.

This attribute sets the directory where journal files are to be written. If no directory is specified, the default path is to the data directory.

This attribute determines whether or not to protect the journal during operating system failures. That is, it determines whether the database forces a file-sync on the journal after every commit. If this attribute is set to "yes", the journal is protected against operating system failures. However, this will slow performance - especially on Windows systems. If set to "no", eXist will rely on the operating system to flush out the journal contents to disk. In the worst case scenario, in which there is a complete system failure, some committed transactions might not have yet been written to the journal, and so will be rolled back.

If set to "yes", eXist will not sync the journal file immediately after every transaction commit. Instead, it will wait until the current file buffer (32kb) is really full. This can speed up eXist on some systems where a file sync is an expensive operation (mainly windows XP; not necessary on Linux).

However, group-comit="yes" will increase the chance that an already committed operation is rolled back after a database crash.

Try to restart the db even if crash recovery failed. This is dangerous because there might be corruptions inside the data files. The transaction log will be cleared, all locks removed and the db reindexed.

Set this option to "yes" if you need to make sure that the db is online, even after a fatal crash. Errors encountered during recovery are written to the log files. Scan the log files to see if any problems occurred.

If set to "yes", a consistency check will be run on the database if an error was detected during crash recovery. This option requires force-restart to be set to "yes", otherwise it has no effect.

The consistency check outputs a report to the directory {files}/sanity and if inconsistencies are found in the db, it writes an emergency backup to the same directory.

This attribute sets the maximum amount of time (expressed in milliseconds) that the query can take before it is killed. The setting can be overwritten in an XQuery by specifiying the option exist:timeout:

declare option exist:timeout "time-in-ms";

Please check the documentation on XQuery options.

This attribute limits the size of XML fragments constructed using XQuery, and thus sets the maximum amount of main memory a query is allowed to use. This limit is expressed as the maximum number of nodes allowed for an in-memory DOM tree. The purpose of this option is to avoid memory shortages on the server in cases where users are allowed to run queries that produce very large output fragments. The setting can be overwritten in an XQuery by specifying the option exist:output-size-limit:

declare option exist:output-size-limit "size-hint";

This attribute is required, and specifies a Java class name used to implement the org.exist.security.SecurityManager interface, as in the following example:

<security class="org.exist.security.LDAPSecurityManager" />

eXist is distributed with the following built-in security manager implementations:

Password encoding can be set to one of the following types:

1. plain - Applies plain encryption.
2. md5 (default) - Applies the MD5 algorithm to encrypt passwords.
3. simple-md5 - Applies a simplified MD5 algorithm to encrypt passwords.

The realm to use for basic auth or http-digest password challenges.

Specifies whether string comparisons are to be case-sensitive. This option applies to XPath equality tests (i.e. "=" operator), as well as functions such as contains(), starts-with() and ends-with(). This setting does not apply to operators or functions of the fulltext index (e.g. "&=", "|=", "near()") or the n-gram index, which are never case-sensitive

Setting caseSensitive="yes" violates the XQuery specs! The option should be regarded as a dirty workaround, which will be removed in the future. Please use the n-gram or full-text indexes for case-insensitive queries or - if that is impossible - specify a collation.

Specifies how the <indexer> is to treat whitespace at the start or end of a character sequence. This option ONLY applies to newly stored files, and therefore changing it has no effect on previously stored documents. Possible values for this attribute are:

1. leading - Suppresses leading whitespace.
2. trailing - Suppresses trailing whitespace.
3. both - Suppresses leading and trailing whitespace.
4. none - Preserves all whitespace.

Note that suppressing whitespace at the start or end of character sequences does effectively change the document!

controls how ignorable whitespace is handled. If set to no, ignorable whitespace, e.g. between the end tag of an element and the start tag of another, will not be stored into the persistent DOM. This leads to a smaller DOM and usually increases the readability of the XML. Ignorable whitespace is not considered as a part of the logical document model, so removing it doesn't change the document.

This attribute invokes the Java class used to tokenize a string into a sequence of single words or tokens, which are stored to the fulltext index. Currently only the SimpleTokenizer is available.

This attribute specifies the depth of the DOM index, or the tree level up to which elements will be added to the index. For example, a value of "2" results in the document root node and all its child elements being indexed; a value of "1" only indexes the root node.

The DOM index maps unique node identifiers to the nodes' storage locations in the DOM file. Generating this index is time- and memory-consuming. It is furthermore primarily needed to access nodes by their unique node identifier - for example, when serializing XML data for query results or XUpdate - which are operations not normally considered time-critical. Moreover, most XPath expressions can do without this index since they use short-cuts to access the node directly.

Beginning with version 0.9, only top-level elements are added to the DOM index, whereas attributes and text nodes are always excluded. This results in much smaller index sizes and, consequently, a smaller dom.dbx file size. Usually, setting the index-depth to a value of "2" offers a reasonable compromise of index size and performance. However, if your documents are deeply-structured, you might consider increasing this setting to a level of 3, 4 or 5. For example, if the longest path from the document root to an element node has greater than ten node levels, an index-depth setting of 4 or 5 would probably help to increase overall query performance for some types of queries.

This attribute defines the default setting for the validation of documents by the XML parser. If it is set to "no", documents will never be validated against an existing DTD or schema. A value of "auto" will leave document validation to the SAX parser (i.e. the Xerces parser).

Startup jobs are executed once during database startup, but before the database becomes available. These jobs are synchronous. The database is blocked to outside requests and no other operations will run at the same time.

System jobs require the database to be in a consistent state. The scheduler will run them in an exclusive environment. Once the job is triggered, the database will block all new requests and wait for running operations to complete. It then executes the job. All other database operations will be stopped until the job returns or throws an exception. Any exception will be caught and a warning written to the log.

User jobs may be scheduled at any time and may be mutually exclusive or non-exclusive

The type of the job to schedule. Must be either "startup", "system" or "user".

If the job is written in Java then this should be the name of the class that extends either

• org.exist.scheduler.StartupJob
• org.exist.storage.SystemTask
• org.exist.scheduler.UserJavaJob

If the job is written in XQuery (not suitable for system jobs) then this should be a path to an XQuery stored in the database. e.g. /db/myCollection/myJob.xql XQuery job's will be launched under the guest account initially, although the running XQuery may switch permissions through calls to xmldb:login().

To define a firing pattern for the Job using Cron style syntax use this attribute otherwise for a periodic job use the period attribute. Not applicable to startup jobs.

Can be used to define an explicit period for firing the job instead of a Cron style syntax. The period should be in milliseconds. Not applicable to startup jobs.

Can be used with a period to delay the start of a job. If unspecified jobs will start as soon as the database and scheduler are initialised.

Can be used with a period to define for how many periods a job should be executed. If unspecified jobs will repeat for every period indefinitely.

This attribute determines whether <xinclude> tags are to be expanded during serialization. Setting the value to "false" will leave <xinclude> tags unexpanded.

This attribute (when set to "true") tells the serializer to pass its output to an XSL stylesheet when it encounters an XSL processing-instruction at the start of the document.

This attribute tells the serializer to add debug information to each element expressed as additional attributes. This information includes the internal identifier of the node and source document. These are the accepted values:

1. all - Adds debug information to every node in the output.
2. element - Adds debug information to top-level elements only.
3. none (default) - Disables debugging feature.

The serializer defaults to pretty-print the resulting XML source code. Set this option to "no" to disable pretty-printing.

The database can highlight matches in the text content of a node by tagging the matching text string with <exist:match> . Clearly, this only works for XPath expressions using the fulltext index. Set the parameter to "yes" to disable this feature.

This attribute defines the maximum number of page splits allowed within a document before a defragmentation run is triggered.

This attribute is for or debugging purposes only. If the parameter is set to "yes", a consistency check will be run on modified documents after every XUpdate request. This checks whether the persistent DOM is complete, and all pointers in the structural index point to valid storage addresses that contain valid nodes.

enables or disables the java binding. Giving users full access to all Java classes should be considered a security risk and the feature is thus disabled by default. If you enable it, you should think about configuring XACML to restrict Java access from XQuery.

enables or disables XQuery functions marked as deprecated.

set to "yes" if a call to doc(), xmldb:document(), collection() or xmldb:xcollection() should raise an error (FODC0002) when an XML resource can not be retrieved.

set to "no" if a call to doc(), xmldb:document(), collection() or xmldb:xcollection() should return an empty sequence when an XML resource can not be retrieved.

the query engine can often achieve considerable performance improvements by rewriting an XQuery expression into a more efficient form (see the documentation about indexing). However, these features are relatively new. If you have doubts about the correctness of a query result, you may temporarily set enable-query-rewriting to "no" and see if the result changes in any way. If it does, you have hit a bug which should be reported.

enables or disables XPath 1.0 backwards compatibility. The setting mainly effects automatic type conversions, which were less strict in XPath 1.0 than in XQuery/XPath 2.0.