Public: Concord Software Projects : OTrunk Jackrabbit Evaluation
This page last changed on Jul 23, 2008 by scytacki.
We are looking at using jackrabbit to help solve a few different issues:
This would support new features
This would make the system more robust:
At regular intervals send all changes up to the server which haven't been sent before. This should be done asynchronously, so the learner doesn't have to wait for this operation to complete.
Jackrabbit has beta support for remoting jcr over webdav. This is done through the SPI stack.
JCR uses the concept of transient objects. So code using JCR can create a set of transient objects and then only store them when they are complete. This is done by calling save on a object or on the entire session. The jcr2spi -> spi2dav layer sends the objects over the network when save is called.
It is not clear in the jcr2spi -> spi2dav how the JCR read methods work. Do they update all the time, or do they only update on changes, or do they only update once. I saw tests for what looked like different versions of this but haven't explored it yet.
Using the basic stack described above cannot meet the requirements. This is for performance and consitency reasons. Instead a local copy of each object needs to be maintained and then these are asynchronously written into the jcr nodes and then saved.
This would result in all the unsaved transient objects to be saved over the network. This doesn't work because save is not thread safe so all write calls need to stop during the save. If a user is in the middle of drawing, or writing they would have to wait for this to complete. If the save is done in another thread then the stored objects might not be internally consistent, and some object might be marked saved when really they have been modified.
This would result in consistent data, but the performance is too slow since each key stroke or object movement has to wait for the save to complete.
Implementing this seems like the only option. It can be done a couple of ways:
The first option would solve two problems at the same time, but it might be too heavy weight. The second option is lighter weight but would duplicate synchronization/replication effort
One difficult design choice is how to deal with reading the data:
Amount of effort for number 1
Amount of effort for number 2
|Document generated by Confluence on Jan 27, 2014 16:52|