[
https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523831
]
Claus Köll commented on JCR-926:
--------------------------------
ok great work to both of you :-)
I think only one datastore is not a good way.
we have jackrabbit running in a model 3 architecture with one repository and
for each application one workspace.
the problem is not the backup solution, we would prefere backup incremential by
third party solutions.
at the moment we define for each workspace different persistencemanagers to
different db servers.
we want for each workspace "application" define different SAN storage places,
because we must discount the
storage volume for each application. if we have only one datastore it is not
possible to know how much
space each application consumes.
hope for a feature to define that.
one thing at the end ... what do you mean with
> Deleted only when no longer used (by the garbage collector).
the files in the datastore are the permanent files or not ?
thanks
claus
> 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.
