jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock testassumes that changes in one session are immediately visible in differentsession
Date Mon, 11 Feb 2008 09:37:10 GMT
David Rauschenbach wrote:
> Yeah, I think I hear what you're saying, and I understand that tight
> spot. I have to confess that I also use JCR2SPI as the primary client
> for SPI. But I have performance problems to solve, so that <n> JCR calls
> don't explode into <n>*6 SPI invocations, so I have to play all kinds of
> tricks now, to divine extra information from the client and/or server.

we should definitely improve that situation. so far we didn't invest too much 
time in performance analysis but first wanted to have an SPI stack that works 
correctly. I also think that it is now time to carefully analyze the message 
complexity for each JCR call and if needed change the SPI interfaces.

> I like SPI because of its simplicity. But performance is problematic, and
> outside of my control right now, [...]

please let us know what issues you have with the SPI stack. feedback is always 
welcome and gives us an additional view on the SPI that we probably overlooked 
in the past.

you are also welcome to gain control ;) if you have ideas how to improve the SPI 
stack or have patches, please let us know and we will be happy to consider them.

> [...] and I have caches and NodeTypeManagers in my SPIs, even though I am not
>  supposed to.

at some point node type definitions were requested extensively. JCR-1030 should 
have improved that situation.

> I also have my own PathElement comparators, to get SPI to work,
> so that 0 (unspecified) and 1 (default) indexes are considered equivalent,
> but that is another story...

Can you please describe in more detail why you had to do this?


View raw message