Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Sat, 12 Mar 2011 23:24:59 +0000 (UTC)
From: "julien revel (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <2058586161.15738.1299972299419.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Created: (JCR-2913) Shared nodes disappear suddenly -
 Database corruption : Cannot delete nodes anymore : Error is Node with id
 'X" does not have shared parent with id: 'Y'
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Shared nodes disappear suddenly - Database corruption : Cannot delete nodes anymore : Error is Node with id 'X" does not have shared parent with id: 'Y'
--------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JCR-2913
                 URL: https://issues.apache.org/jira/browse/JCR-2913
             Project: Jackrabbit Content Repository
          Issue Type: Bug
            Reporter: julien revel
            Priority: Critical


This problem occurs on a following configuration
- JCR 2.3 Snapshot
- Tomcat 6
- Postgresql 9.0

Jackrabbit is embedded within a Spring application, that communicates with clients in AMF format (Flex client)

The symptom is that some shared Nodes have disappeared from the repository, without having deleted by our application (and we checked a lot already).
Then, repository seems to be corrupted, because it becomes impossible to delete any ancestor node of those having disappear.

The error is not reproducible, it may happen at any time, it is random.
Sometimes, with a fresh base, after creating some nodes, sometimes it happens after a while, when playing with the application.
It never happened on Jetty/Derby development server, but always happened on servers with Postgres, even with a single user.

I guess it is not a bug in JCR, but that we provoked the problem in some way. Maybe by multi-threading  ? 
However, for each remote call that send data to write, we create a new JCRSession, then save it multiple times, then close it.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira