On 30 Mar 2004 at 16:26, [EMAIL PROTECTED] wrote: > >>If you use the slide API for storing data from your app, take into > >>account that it is reallly complicated to store content in a way that > >>you can use the versioning stuff, because all of the versioning is done > in the webdav layer. > > What do you mean ? The slide API can manage NodeRevisionDescriptors and > NodeRevisionDescriptor. > It is not what you expect to do ? or are you speaking about other features ? > > >>For fast content retrieval in the same vm, slide > >>API might be a good choice. > > I'm using the Slide API from a Jetspeed service and its works fine. We have > -/+ 20.000 documents and no problem at all. > Maybe, if we have more and more documents, this solution will not be > scalable. So, next plan is to access to different "external" repositories > via the webdav client.
Hi Christophe, there are major performance issues in the Slide kernel and database layer. 1. A collection SubjectNode always knows about all its children. With increasing collections the time to retrieve a collection SubjectNode will increase. Apart from this all children SubjectNodes are instanced to prepare the binding information. Solution would be to load the information about the children only on demand. To do this, the SubjectNode needs a pointer to the right NodeStore, which in turn needs some new methods. I implemented this with sub-classing the SubjectNode, which had been made more complicated than necessary with some private members and methods in ObjectNode :-( Of course some WebDAV methods need adaption to use the custom SubjectNode. 2. When adding a new child to a collection resource, all the old child entries of the collection resource are deleted, just to be saved again afterwards together with the information about the new child. The same is true for removing children. Solution would be to enhance the NodeStore interface with methods such as addChild and removeChild or so. Of course StructureImpl needs to be adapted too. Having done these two enhancements, I can tell you the performance has increased dramatically, especially when talking about many documents (>1000). Nevertheless, the old database schema with "slow" datatypes (CLOB), which I had to use when doing the changes, prevents the usage of Slide with really many documents: On a server with 150,000 documents (70,000 in one collection) a put of a new document still needs a few seconds -- and unfortunately is rising with every new document. Maybe the new database schema is much better in this regard, but the two problems above remain. Regards, Andreas > > Christophe > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
