Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <419428724.1235116504710.JavaMail.jira@brutus>
Date: Thu, 19 Feb 2009 23:55:04 -0800 (PST)
From: "Martijn Hendriks (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-1117) Bundle cache is not rolled back when the
 storage of a ChangeLog fails
In-Reply-To: <24934524.1189431569576.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.