[
https://issues.apache.org/jira/browse/JCR-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782361#action_12782361
]
Stefan Guggisberg commented on JCR-2407:
----------------------------------------
> [...] were the blobs are stored through the PM in the database.
this explains it. blobs read from a db are spooled to the local file system for
performance reasons, that's by design.
we could e.g. change the caching behavior of the SharedItemStateManager to not
'cache' PropertyState instances with temp-file based binary values. but that
seems a bit ugly.
another option would be to read the binary value on demand. this would however
impact performance and would require to tie the Value implementation directly
to the persistence layer. we deliberately avoided this in the past since that
would sigificantly compromise the current design.
BTW: please note that the SharedItemStateManager 'cache' is not just a cache in
the traditional sense but also an integral part of jackrabbit's isolation level
support (read committed).
> Make the disk space used by cached binary properties configurable
> -----------------------------------------------------------------
>
> Key: JCR-2407
> URL: https://issues.apache.org/jira/browse/JCR-2407
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.0-beta1
> Reporter: Martijn Hendriks
>
> Binary properties which are in Jackrabbit's caches (SharedItemStateManager
> eg) are stored on disk in the temp dir. This can cause problems on small
> temporary file systems as the size of the binary properties on disk is not
> limited by Jackrabbit. There is one way to influence this indirectly: make
> the Jackrabbit cache sizes smaller (via the CacheManager). It could be
> helpful in some cases if an upper bound on the disk usage can be given.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
