Yes, the problems you mentionned in your mail are well know.
It should be nice to see this kind of performance enhancement into the Slide distribution.
Can you send me your modification ? I'm really interesting to have this kind of perf improvement for my onw application.
Oliver, I think you are more focusing on the Slide kernel, what do you think about that ?
I would like to make the following proposal :
Silimar to the security helper class, it should be nice to add new parameters into the Slide domain.xml in order to choose the classes name for all helpers classes (structure, lock, search, ...).
It is quite easy to do it in the NamespaceAccessTokenImpl. The same think can be done for search languages in the SearchImpl class.
It can gives more flexibilty to the slide user and maybe optimize some code in function of the application needs.
If all committers are agree, I can send something for that. I already did something for the search languages.
Christophe
Andreas Probst wrote:
On 30 Mar 2004 at 16:26, [EMAIL PROTECTED] wrote:
in the webdav layer.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
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 ?
I'm using the Slide API from a Jetspeed service and its works fine. We haveFor fast content retrieval in the same vm, slide API might be a good choice.
-/+ 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
