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).
- 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 184.108.40.206 "element() Node Test")
- 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 220.127.116.11 "Seeing Changes Made by Other Sessions").
InvalidItemStateExceptions 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 UnsupportedRepositoryOperationException if the node is not mix:referenceable (section 18.104.22.168 "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)