v5.0.0-RC1 - June 9, 2018
We are very excited to announce the first Release Candidate (RC) for eXist-db 5.0.0.
- NOTE: A Release Candidate is not recommended for production use. We have tested the release extensively, and we now invite all users to report both their positive and negative experiences with it. As always please make sure you have frequent and correct backups of your database.
The core improvements to eXist-db's locking, concurrency, and transactions in 5.0.0-RC1 represent a huge amount of work contributed by Evolved Binary. For in-depth information on these changes, see Evolved Binary's technical reports: Locking and Cache Improvements for eXist-db and Asymmetrical Locking for eXist-db.
In eXist-db 5.0.0-RC1, all locking interactions have been redesigned and reimplemented from the ground up; a number of deadlock paths have been removed; and many operations have been redesigned to be thread-safe. The result is that eXist-db should exhibit better responsiveness under concurrent user operations. For example, because collection locks are now multi-read capable, re-indexing the database no longer blocks access to the collection being re-indexed. Users should notice improved responsiveness during such operations.
5.0.0-RC1 also contains some security fixes and bug fixes that necessitated API changes and thus were not suitable for the existing 4.x.x line.
- Hierarchical locking strategy for Collection locks.
- Centralised Lock Manager, which feeds a Lock Table for reporting to the user on lock leases and pending lock acquisitions (with JMX support).
- All bespoke locks have been removed and/or replaced with standard Java library locks.
- Managed Lock wrappers for ARM (Automatic Resource Management), to ensure locks are never left dangling.
- Most operations now exploit deadlock avoidance strategies.
- Asymmetrical locking between Collection and Document locks; Collection locks now have shorter leases.
- Collections now exploit read/write locking, rather than Mutex locking; multiple reads can happen in parallel.
- Complete rewrite of Collection Caching using Ben Mane's Caffeine library.
- Reduced Transaction overhead, by reusing existing transactions.
- Updated Saxon for XSLT to 9.8.0-12.
- XQuery function signatures are more closely aligned to the W3C XQuery specification.
util:eval-with-contextnow offers a timeout argument.
- Copy APIs now offer a
preserveflag, which behaves similarly to GNU cp's
- Implemented simplified
- The last used User and Group id's are no longer exported during a database Backup, nor are they read back from a Backup when Restoring. As such the format of the file
/db/system/security/config.xmlhas changed. #1858.
- XML-RPC and XML:DB Remote APIs now use GZip encoding for streams and not Zip. This introduces a non-backwards compatible change to the XML-RPC API which also affects the Java Admin Client. #1903.
- Numerous erroneous locking states (see Evolved Binary's Technical Reports).
- The format of
/db/system/security/config.xmlhas changed. You can restore Backups from previous versions of eXist-db. However, you cannot restore a Backup from eXist-db 5.0.0-RC1 to a previous version of eXist-db.
- The XML-RPC API is not 100% backwards compatible with prior versions of eXist-db, particularly with regards to uploading/downloading documents. You should always use the correct version of the Java Admin Client with eXist-db.
- Versions of the Dashboard App prior to version 1.1.0 are not compatible with eXist-db 5.0.0-RC1. If you wish to migrate from an older version of eXist-db, you must first update both the Shared Resources package and the Dashboard package on your existing eXist-db version to at least versions 0.6.0 and 1.1.0 respectively. If you are starting with a new clean install of eXist-db 5.0.0-RC1 you have nothing to worry about.
eXist-db v5.0.0-RC1 is backwards binary-compatible as far as v3.0, but not with earlier versions. Users who are upgrading should always consult the Upgrading Guide in the documentation.