jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: Model 3 deployment status
Date Thu, 29 Sep 2005 23:42:20 GMT
#: Jukka Zitting changed the world a bit at a time by saying on  9/30/2005 12:23 AM :#
> Hi,
> Alexandru Popescu wrote:
>>> Another more advanced optimization would be to host the
>>> entire transient session state at the client side and only
>>> sending changes over the network when the save() method is invoked.
>> Shouldn't this be required to happen? (session `flushing´ only on 
>> save). In all other cases I think that the remote repository should 
>> have a session management mechanism that is reusing the same session 
>> for a client that haven't submitted yet the save() ).
> The API obviously suggests an implementation like that. This is however no
> strict requirement, and the transient state can therefore be managed on either
> side of the network link. The fact that JCR-RMI is a layer *on top of* the JCR
> API makes it much easier to keep the transient state on the server side 
> than on
> the client side, thus causing the performance issues. A network layer 
> that works
> *below* the JCR API could easily be made much more efficient, but the downside
> is that such a layer would be tightly bound to a single repository
> implementation.
> In fact it would be quite interesting to investigate the feasibility of such a
> network layer for Jackrabbit. Do any of the other content repository
> implementations implement anything like that? Is there general interest in a
> such a feature? If there is enough interest we might want to consider
> implementing something like that somewhere around Jackrabbit 1.2 or 2.0. :-)

If you are referring to a rmi communication layer I've got answers from exo-jcr that they
supporting the same scenario. But because exo-jcr RC1 was announced in may and nothing new
released I haven't spent time investigating this (they don't support yet optional features,
so it 
was not so interesting to me).

The same question went to the CRX, and I guess the answer is obvious. I don't know anything
jeceira but it is very very young so I don't think the guys there have spent a lot of time
on this.

>>> [...]
>>> the biggest performance issues by the time the Jackrabbit 1.0 
>>> release is made.
>> Are we talking about something scheduled here :-) ?
> :-) Well, you know the open source schedules, it's ready when it's ready...
> Anyhow, I'd be surprised if JCR-RMI performance would not be much improved by
> the end of this year. All sorts of help (bug reports, comments, docs, patches,
> testing, etc.) is of course very much welcome.
> As for the Jackrabbit 1.0 schedule, I'll get back to that soon enough in a
> separate message.

I am getting the feeling you are preparing us a surprise ;-).

.p( the_mindstorm )q.

> BR,
> Jukka Zitting

View raw message