Jackrabbit in general is a fully JCR-1.0 (Jackrabbit versions 1.x) and JCR-2.0-compliant (versions 2.x) Java content repository implementation. As the spec does not mandate every detail, Jackrabbit has to use a specific implementation in some cases and it also contains some additional features. This page shall give an overview.
Please note that this list is not complete and currently mixes JCR 1.0 and JCR 2.0 aspects (albeit they generally match). If you have any questions on this topic, the best place to ask are the jackrabbit mailing lists (start on the users list).
Additional Features
- XPath element() function also allows for mixin node types in the second argument (not only primary node types as mandated by the spec in section 6.6.4.13 "element() Node Test")
Implementation Choice
- Changes made by different sessions: Jackrabbit employs a copy-on-write model, ie. any non-modified item in one session will always reflect the persisted state of that item (section 7.1.3.4 "Seeing Changes Made by Other Sessions").
- {{InvalidItemStateException}}s on concurrent modifications: complex issue, see JCR-1552 for details
- UUID assignment: Jackrabbit's implementation uses UUIDs internally as well, so these are already assigned upon creating a node and will not change upon a save(). Note that Node.getUUID() will nevertheless throw an
UnsupportedRepositoryOperationExceptionif the node is not mix:referenceable (section 4.9.1.1 "When UUIDs are Assigned"). - A query runs against the content of its bound persistent workspace, without regard to any pending changes in its bound transient store. (section 6.12.2 Queryable Content of JCR 2.0)