Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <44040F4A.1080604@gmx.net>
Date: Tue, 28 Feb 2006 09:52:26 +0100
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: recovering from unclean shutdown
References: 
 <2969645.1141065800002.OPEN-XCHANGE.WebMail.www-data@saturn.intern.systemone.at>
In-Reply-To: 
 <2969645.1141065800002.OPEN-XCHANGE.WebMail.www-data@saturn.intern.systemone.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Manuel Simoni wrote:
> Does the JCR repository ever go into a unknown state, IOW, if I
> encounter a .lock file during startup, can I just delete and ignore it,
> or do I have to recover from a backup, if I want to be on the safe side?

The .lock is only used to prevent multiple jackrabbit instances run on 
the same underlying data. It does not indicate that the repository is in 
an unknown state. You should not have to delete the file manually. 
Jackrabbit will check if the .lock file is actively locked by another 
process and if not remove the .lock file and proceed with regular startup.

If you use a transactional persistence manager (PM) such as 
DerbyPersistenceManager the repository should never go into an unknown 
state. If it does then it's a bug.
A transactional PM guarantees that a JCR transaction is always applied 
as a whole or not at all.

There is a slight chance that the lucene index that jackrabbit uses to 
execute queries goes out of sync. Changes on the index and the PM are 
currently handled sequencially and not in a two-phase commit.
See also: http://issues.apache.org/jira/browse/JCR-204

regards
  marcel