jackrabbit java_Apache Jackrabbit 常见问题
Persistence managers
A persistence manager (PM) is an internal Jackrabbit component that handles the persistent storage of content nodes and properties. Each workspace of a Jackrabbit content repository uses a separate persistence manager to store the content in that workspace. Also the Jackrabbit version handler uses a separate persistence manager.
The persistence manager sits at the very bottom layer of the Jackrabbit system architecture. Reliability, integrity and performance of the PM are crucial to the overall stability and performance of the repository. If e.g. the data that a PM is based upon is allowed to change through external means the integrity of the repository would be at risk (think of referential integrity / node references e.g.).
In practice, a persistence manager is any Java class that implements the PersistenceManager interface and the associated behavioural contracts. Jackrabbit contains a set of built-in persistence manager classes that cover most of the deployment needs. There are also a few contributed persistence managers that give additional flexibility.
A Jackrabbbit file system (FS) is an internal component that implements standard file system operations on top of some underlying storage mechanism (a normal file system, a database, a webdav server, or a custom file format). A file system component is any Java class that implements the FileSystem interface and the associated behavioural contracts. File systems are used in Jackrabbit both as subcomponents of the persistence managers and for general storage needs (for example to store the full text indexes).
No. The persistence manager interface was never intended as being a general SPI that you could implement in order to integrate external data sources with proprietary formats (e.g. a customers database). The reason why we abstracted the PM interface was to leave room for future performance optimizations that would not affect the rest of the implementation (e.g. by storing the raw data in a b-tree based database instead of individual file).
A persistence manager should not be intelligent, i.e. it should not interpret the content it is managing. The only thing it should care about is to efficiently, consistently, and reliably store and read the content encapsulated in the passed NodeState and PropertyState objects. Though it might be feasible to write a custom persistence manager to represent existing legacy data in a level-1 (read-only) repository, I don’t think the same is possible for a level-2 repository and I certainly would not recommend it.
The table below lists the currently available persistence managers, along with the status and pros and cons of each PM.
Persistence manager
Status
Pros
Cons
SimpleDbPersistenceManager (and subclasses thereof)
mature
Jackrabbit’s default persistence manager
JDBC based persistence supporting a wide range of RDBMSs
zero-deployment, schema is automatically created
Transactional
uses simple non-normalized schema and binary serialization format which might not appeal to relational data modeling fans
BerkeleyDBPersistenceManager
mature?
btree-based persistence (BerkeleyDB JE)
zero-deployment
Transactional
Uses binary serialization format
Licensing issues
ObjectPersistenceManager
mature
File system based persistence
Easy to configure
Uses binary serialization format
If the JVM process is killed the repository might turn inconsistent
Not transactional
XMLPersistenceManager
mature
File system based persistence
Uses XML serialization format
Easy to configure
If the JVM process is killed the repository might turn inconsistent
Poor performance
Not transactional
ORM persistence manager
experimental & unfinished
ORM-based persistence
Transactional
Complex to configure & setup
Still being maintained?
The table below lists the currently available Jackrabbit file systems, along with the status and pros and cons of each FS.
File system
Status
Pros
Cons
LocalFileSystem
mature
Slow on Windows boxes
DbFileSystem
mature
JDBC based file system supporting a wide range of RDBMSs
zero-deployment, schema is automatically created
Slower than native file systems
CQFS file system
mature
Fast on Windows boxes
Undocumented configuration options
Proprietary binary format
Not open source
The answer depends on your priorities. If you want to store your data in a RDBMS, use SimpleDbPersistenceManager and either LocalFileSystem or DbFileSystem. If you want to store your data in an accessible format (just in case or for manual debugging), you might want to try the XMLPersistenceManager and the LocalFileSystem. If you use Windows and performance is a must, you might want to try the ObjectPersistenceManager and the proprietary CQFS.