Phil Bingley wrote:
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.
creating a 'fat' remote client for jackrabbit and using jackrabbit in a cluster is basically the same problem. both try to do as much work as possible in isolation from other clients / cluster-nodes while care has to be taken to ensure consistency when changes are actually committed. The second requirement inevitably results in the question how changes in the central storage are propagated to connected clients / cluster-nodes. Which can be quite tricky when one tries to use a connection less protocol ;)
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?.
There are numerous areas that need to be reworked. See jira issue JCR-169.
Am I heading in a bad direction with my ideas or would this be a workable solution?
I think you are heading in the right direction. Feel free to dump your thoughts to the mentioned jira issue.
regards marcel
