[
https://issues.apache.org/jira/browse/JCR-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Hendriks updated JCR-1117:
----------------------------------
Attachment: JCR-1117-v2.patch
The first patch clears the cache too late. Suppose that the storage of a
changelog fails, and blockOnConnectionLoss is true, then storage of the
ChangeLog is retried with the corrupt bundle cache until it succeeeds. If this
succeeds, then possibly corrupt bundles have been flushed to the DB.
> Bundle cache is not rolled back when the storage of a ChangeLog fails
> ---------------------------------------------------------------------
>
> Key: JCR-1117
> URL: https://issues.apache.org/jira/browse/JCR-1117
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.3
> Reporter: Martijn Hendriks
> Assignee: Martijn Hendriks
> Attachments: JCR-1117-v2.patch, JCR-1117.patch, stacktrace.txt
>
>
> The bundle cache in the bundle persistence managers is not restored to its
> old state when the AbstractBundlePersistenceManager.store(ChangeLog
> changeLog) method throws an exception. If, for instance, the storage of
> references fails then the
> AbstractBundlePersistenceManager.putBundle(NodePropBundle bundle) method has
> already been called for all modified bundles. Because of the connection
> rollback, the bundle cache will be out-of-sync with the persistent state. As
> a result, the SharedItemStateManager will have an incorrect view of the
> persistent state.
> Furthermore, if the blockOnConnectionLoss property is set to true, then the
> BundleDbPersistenceManager can be caught in an infinite loop because of
> invalid SQL inserts because of an incorrect bundle cache; see attached
> stacktrace.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
