We are happy to announce the availability of eXist-db release 1.4.3. This version is a maintenance release and contains mainly bug fixes and (stability & performance) improvements. A detailed list of changes is included in this mail.
The software can be downloaded from Sourceforge: https://sourceforge.net/projects/exist/files/Stable/1.4.3/ . We recommend everybody to upgrade to this latest version.
The eXist-db development team.
Summary per SVN revision:
16460 - [bugfix]
Reindex operation needs to lock the collection tree or there might be index corruptions if concurrent threads are uploading data. Port of rev 16414 from trunk.
16601 - [performance]
Optimizer did not analyze typeswitch/switch and except/union/intersect, so expressions below those were not optimized.
Port of rev 16599.
16837 - [performance]
Collection cache was not scaling up properly to the limits set in conf.xml. This was a severe performance issue on databases with lots of collections (> 10000) and documents. The cache has been fixed to scale up to the defined memory limit almost immediately if required.
Port of rev 16836.
16975 - [bugfix]
Avoid unnecessary recovery runs: if a long-running query had to be killed during shutdown, eXist started a recovery run upon next startup - even though all transactions might have been committed. Recovery runs are always risky, so it is better to avoid them. I thus changed the transaction manager to keep track of uncommitted transactions. If there are no uncommitted transactions, a checkpoint will be written and the system will not attempt a recovery. This should improve overall stability.
16976 - [bugfix]
Further improvement on crash recovery: ignore a started transaction, which is otherwise empty (i.e. no write operations were done).
16985 - [bugfix]
Added more checks on the XQuery watchdog and thus allow a long running query to be aborted properly.
17021 - [bugfix]
Set correct module load path for modules imported from URI.
17116 - [feature]
Added configuration option enforce-index-use=strict|always to control how range range indexes will be used if only parts of the collection hierarchy define a matching index or indexes are inconsistent across collections. Experience showed that new users often have problems with the "strict" behavior, which was previously the default. With setting "always" the query engine relies on the user to define the correct indexes. It is easier to see why a certain collection is missing in the result than to understand why a query is breaking down due to inconsistencies in the indexing.
Port of revs 15780, 15781 and 17114 from trunk.
17127 - [bugfix]
Fix lucene match highlighting for phrase queries.
Port of rev 17126
17131 - [bugfix]
Updated mondial.dtd to match mondial XML file