jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Concurrent modifications
Date Sun, 18 May 2008 16:37:50 GMT

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.

View raw message