#: 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 are
supporting the same scenario. But because exo-jcr RC1 was announced in may and nothing new was
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 about
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 ;-).
./alex
--
.p( the_mindstorm )q.
BR,
Jukka Zitting
