Downloaded 538 times
Uploaded byJukka Zitting
Oak, the architecture of Apache Jackrabbit 3
The document provides an overview of the Apache Jackrabbit Oak architecture, detailing its structure, including the tree model and mechanisms for tree updates and concurrency management. It outlines conflict handling strategies, varying implementations, and access control within the system, as well as describing commit hooks and observers used for tracking changes. Additionally, search functionality and performance considerations for different use cases are discussed.
More Related Content
Similar to Oak, the architecture of Apache Jackrabbit 3
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
![谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]](https://cdn.slidesharecdn.com/ss_thumbnails/top233-260130173900-2eb784f9-thumbnail.jpg?width=640&height=640&fit=bounds)
Oak, the architecture of Apache Jackrabbit 3
- 1. Oak the architecture ofApache Jackrabbit 3
- 2.
- 3. Resources • http://jackrabbit.apache.org/oak/ • Docs •http://jackrabbit.apache.org/oak/docs/ • Code • https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/ • https://github.com/apache/jackrabbit-oak • Builds • http://ci.apache.org/builders/oak-trunk/ • https://travis-ci.org/apache/jackrabbit-oak
- 4. Outline • Tree model •Updating the tree • Refresh and garbage collection • Concurrency and conflicts • Interlude: Implementations • Replicas and sharding • Access control • Comparing revisions • Commit hooks • Observers • Search • Big picture
- 5.
- 6. a d b c Pathsas identifiers / /a /a/b /a/c /d
- 7. a d b c Pathsas identifiers / /a /a/b /a/c /d
- 8.
- 9.
- 10. r1 r2 HEAD r1: /dr2: /d r1: /a/c r2: /a/c
- 11. Refresh and garbagecollection
- 12.
- 13.
- 15.
- 16.
- 17.
- 18. Conflict handling strategies a.Fully serialized commits • fail on conflict, no concurrent updates b. Partially serialized commits • fail on conflict, concurrent conflict-free updates c. Partial merge logic • conflict markers, manual conflict resolution d. Full merge logic • conflicting changes may be lost
- 19.
- 20. MicroKernel/NodeStore • Implementation ofthe tree/revision model Responsible for Clustering Sharding Caching Conflict handling etc. Not responsible for Type validation Access control Search Versioning etc.
- 21. Current implementations DocumentMK TarMK(SegmentMK) Persistence backends MongoDB, JDBC (WIP) Local FS (tar files) Conflict handling Partial serialization Full serialization Clustering MongoDB clustering Simple failover Sharding MongoDB sharding N/A Single-node performance Moderate High Key use cases Large deployments (>1TB), concurrent writes Small/medium deployments, mostly read
- 22.
- 23. master copy fullreplica cache Replicas and caches
- 24. by path bylevel by hash Sharding strategies with caching
- 25.
- 26.
- 27. Existentialism • All (syntacticallyvalid) paths can be traversed • But the identified node might not exist • For example: root.getChildNode(“a”).exists() -> false root.getChildNode(“a”).getChildNode(“b”).exists() -> true! • Implemented as a decorator over the MK
- 28.
- 29.
- 30. Content diff • Tellswhat changed between two content trees • Cornerstone of most higher-level functionality • validation • indexing • observation • etc.
- 31. r1 r2b r2a r3 Examples r1 -> r3 “a”modified “b” removed “d” modified “e” added r1 -> r2a “a” modified “b” removed r1 -> r2b “d” modified “e” added
- 32.
- 33. If this changed,commit this instead
- 34. Commit hooks • Basedon given before and after states, a hook can: • fail the commit, or • pass the commit unmodified, or • pass the commit with modifications • Key plugin mechanism in Oak • All configured hooks are applied in sequence • Used for much higher level functionality • Often implemented using a content diff
- 35. Examples • All kindsof validation • node types, access control, references, etc. • Trigger-like functionality • autocreated content, default values, etc. • In-content index updates • etc.
- 36. Types of hooks CommitHookEditor Validator Content diff Optional Always Always Can modify commit Yes Yes No Programming model Simple Callbacks Callbacks Performance impact High Medium Low
- 37.
- 38. Observers • Based ongiven before and after states, an observer can: • observe what changed in the content tree • Invoked after the commit, unlike commit hooks • Always asynchronous for changes from other cluster nodes • Depending on backend, can be synchronous for changes on the local cluster node • Often implemented using a content diff
- 39. Examples • JCR Observation •External index updates • Cache invalidation • Logging • etc.
- 40.
- 41.
- 42. Query processing steps 1.Parsing a. Select matching parser b. Parse the query string 2. Execution a. Estimate cost per index b. Select index with the least cost estimate c. Execute the query against the index 3. Post-processing a. Filter results on access control and additional constraints b. Apply sorting, grouping, faceting, etc.
- 43. Index implementations • Propertyindex • Reference index • Lucene index • in-content • local file system • Solr index • embedded • external
- 44.
- 45. MicroKernel Oak Core Oak JCR OakAPI NodeStore API JCR API Plugins
- 46.