Explanation and use cases of JCR workspace for human beings

Could please anybody interpret JCR 2.0 specification in regard to JCR workspaces ?

I understand that a session is always bound to exactly one persistent workspace, though a single persistent workspace may be bound to multiple sessions.

Which probably relates to versioning and transactions, though I don't know why.

Some observations :

• references are only possible between nodes of the same workspace
• executing a query will always be targeted to a single workspace

Workspaces seem to be about nodes that represent the same content (same UUID), in :

• different versions of "something", project maybe ?
• differ开发者_开发技巧ent phase of workflow

And shouldn't be used for ACL.

Also in JackRabbit, each workspace has its persistence manager. Whereas ModeShape has a connector for source - workspace independent.

---

David's model ( http://wiki.apache.org/jackrabbit/DavidsModel ) Rule #3 recommends using workspaces only if you need clone(), merge() or update(). For the vast majority of JCR applications, this means not using workspaces. Putting things under different paths, setting specific property values or mixin node types on them and using JCR's versioning covers the versioning and workflow use cases that you mention.

To manage print jobs for example, you could simply move them between JCR folders named "new", "in-progress", "rejected" and "done". That's how it is done in some unix versions, using filesystem folders. JCR allows you to do the same, while benefitting from its "filesystem on steroids" features, so as to keep things very simple, transparent and efficient.

Note also David's Rule #5: references are harmful - we (Apache Sling and Day/Adobe CQ /CRX developers) tend to just use paths instead, as looser and more flexible references.

And as you mention queries: we also use very few of those - navigation in a JCR tree is much more efficient if your content model's path structure makes sense for the most common use cases.