Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.20 as permitted sender)
Message-ID: <48305B5E.2090204@gmx.de>
Date: Sun, 18 May 2008 18:37:50 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: Concurrent modifications
References: <480E1AAF.3050007@gmx.de> <480E1C3F.7080502@gmx.de>
 <481F0251.8090505@gmx.de>
In-Reply-To: <481F0251.8090505@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

OK,

I saw no feedback on this.

Unless there are some immediate objections, I'll thus open a ticket 
against JCR2SPI inability to pass the Session.refresh() call down to the 
SPI layer.

BR, Julian


Julian Reschke wrote:
> OK,
> 
> sorry for getting back to this discussion late.
> 
> I modified the test case so that the InvalidItemStateException indeed 
> occurs with jackrabbit-core (see attachment).
> 
> I think we have consensus that JSR-170 doesn't require a store to behave 
> like that; it's truly optional.
> 
> Now, with the same test and with jcr2spi (connecting to jackrabbit-core 
> through spi2jcr) the InvalidItemStateException is *not* thrown.
> 
> This doesn't come as a surprise, because -- as far as I understand -- 
> JCR2SPI lacks the necessary information to do so.
> 
> It seems to me that the SPI APIshould *allow* stores to expose the same 
> behaviour as jackrabbit-core, and the simplest way to achieve that would 
> (IMHO) be to allow the SPI implementation to keep state. (*)
> 
> Feedback appreciated,
> 
> Julian
> 
> (*) Right now, when it does keep state, we see TCK failures, as JCR's 
> refresh() method is not delegated to the SPI SessionInfo. I think we 
> need to fix that.
> 
> 
>