> > 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. >
While I am new to Jackrabbit, I for one would love to see an implementation like that. I have been looking at my options for an implementation of jackrabbit and felt that I couldn't achieve exactly what I needed with jcr-rmi because of the performance issues. In this case, doesn't it amount to creating remotable versions of things like the PersistenceManager and FileSystem - at least things at a layer similar to them. It feels to me like having JCR able to sit on top of the network layer might make the clustering issue easier to overcome also. Ideally I'd like to be able to have a rich client use the JCR API remotely against the same data as a webapp using the JCR API with local calls to the underlying data. I was thinking that I'd be able to implement a PersistenceManager etc to enable this but after doing a lot of reading there would be caching etc internal to JackRabbit that would stop this from working. This is basically what gets in the way of clustering isn't it?. Am I heading in a bad direction with my ideas or would this be a workable solution? Cheers, Phil ===================================================================== CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. ================================================================ For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz ================================================================
