[ https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523852 ]
Jukka Zitting commented on JCR-926: ----------------------------------- A central idea of the *Global* Data Store is that its global to the repository, especially to drive down the costs of versioning and other cross-workspace operations. It would in principle be feasible to allow a workspace-specific data store to be configured, but that would make handling of cross-workspace operations considerably more complex. IMHO the benefits of workspace-local data stores wouldn't be worth the added complexity. On a longer timescale I also believe Jackrabbit should be moving even more to centralized repository-global resource handling as that would for example help a lot in making things like versioning operations transactional. As for features like per-workspace quota or backups, I think those would be best achieved by implementing the features in Jackrabbit instead of relying on the underlying storage mechanism. > Global data store for binaries > ------------------------------ > > Key: JCR-926 > URL: https://issues.apache.org/jira/browse/JCR-926 > Project: Jackrabbit > Issue Type: New Feature > Components: core > Reporter: Jukka Zitting > Attachments: dataStore.patch, DataStore.patch, DataStore2.patch, > dataStore3.patch, dataStore4.zip, dataStore5-garbageCollector.patch, > internalValue.patch, ReadWhileSaveTest.patch > > > There are three main problems with the way Jackrabbit currently handles large > binary values: > 1) Persisting a large binary value blocks access to the persistence layer for > extended amounts of time (see JCR-314) > 2) At least two copies of binary streams are made when saving them through > the JCR API: one in the transient space, and one when persisting the value > 3) Versioining and copy operations on nodes or subtrees that contain large > binary values can quickly end up consuming excessive amounts of storage space. > To solve these issues (and to get other nice benefits), I propose that we > implement a global "data store" concept in the repository. A data store is an > append-only set of binary values that uses short identifiers to identify and > access the stored binary values. The data store would trivially fit the > requirements of transient space and transaction handling due to the > append-only nature. An explicit mark-and-sweep garbage collection process > could be added to avoid concerns about storing garbage values. > See the recent NGP value record discussion, especially [1], for more > background on this idea. > [1] > http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200705.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.