Hi, the week before Xmas, my colleague Michael Hartmeier and me were dealing with making two techniques which we used in the Tamino store generally available in Slide: t-locking and resolving.
What it is. T-locking stands for "transient locking" and makes store implementations more robust against the parallel access ... even if the underlying datastore (e.g. filesystem) doesn't support the required level of isolation. By means of t-locking, during a Slide transaction, resources can be protected by READ or WRITE t-locks. Resolving is required to make a store implementation *binding* enabled. Binding refers to the ability of assigning multiple URIs to the same resource (see http://webdav.org/bind). As in a binding enabled store implementation the URI does not anymore uniquely identify a resource, an alternate unique resource identifier (resource-ID) is required. Resolving refers to the process of finding the associated resource-ID for a given URI. What we did. So, we provided a new parent store implementation "ParentStore" (still looking for a more appealing name :)) which we made extend "ExtendedStore" to take advantage of Oliver's caching facilities. ParentStore adds t-locking and resolving, of course. As ExtendedStore is still the default parent store implementation, ParentStore has to be enabled explicitly in the store definition: <store name="tx" classname="org.apache.slide.store.ParentStore"> <parameter name="useBinding">true</parameter> <nodestore classname="org.apache.slide.store.txfile.TxXMLFileDescriptorsStore"> <parameter name="rootpath">tx/store/metadata</parameter> <parameter name="workpath">tx/work/metadata</parameter> </nodestore> ... <contentstore classname="org.apache.slide.store.txfile.TxFileContentStore"> <parameter name="rootpath">tx/store/content</parameter> <parameter name="workpath">tx/work/content</parameter> </contentstore> </store> Binding can be en-/disabled by means of the per-store parameter "useBinding" (see above). Be sure that the global switch for binding in slide.properties is ON: org.apache.slide.binding=true We tested with Oliver's TX store. In order to binding-enable it, the only thing we needed to do was to make sure that the node store saves the *binding* vectors instead of the *children* vector of ObjectNode. We added a class "ResourceId" extending org.apache.slide.common.Uri. It holds a "unique URI" in its state which we internally called UURI and which uses the registered URI-scheme urn:uuid:. So, the parentStore mainly converts between URI and UURI. If binding is disabled, URI=UURI holds and no conversion takes place. Roughly speaking, for a method of the store interface (e.g. revokePermissions), the implementation in ParentStore looks like: public void revokePermissions(Uri uri) throws ServiceAccessException { try { super.revokePermissions(obtainResourceId(uri)); } catch (ObjectNotFoundException e) { throw new ServiceAccessException(this, e); } } So, if binding is enabled, caching in the ExtendedStore takes place on the base of UURIs. Our test results. We used Tomcat 4.1.27 and Oliver's TX store. We run the "functional" testsuite with/without binding, and by including/excluding the "multi-user" testcases inside "functional" (E=ExtendedStore, P=ParentStore): ----------------------------------------- Store E E P P P P Binding Y Y Multi-user Y Y Y ----------------------------------------- Total 210 212 210 210 212 212 Failed 0 40 0 0 3 0 Elapsed 200 482 193 189 337 397 ----------------------------------------- We started the testsuite as follows: TProcessor.CMD -pattern *cases\\functional* -exclude *multi-user* TProcessor.CMD -pattern *cases\\functional* -users 4 -iterations 4 Conclusions. We observed that the ParentStore is as stable as the ExtendedStore, but adds stability in the case of multi-user tests. Also, we could not observe any substantial loss of performance by using the ParentStore. Open issues. 1) All child store implementations (MySQL, JDBC, etc.) should save the *binding* vectors instead of the children vector of ObjectNode. 2) ParentStore could become the default parent store implementation as soon as it proves to be stable. 3) As resolving appears to be expensive, it seems senseful to cache the mapping URI -> UURI inside a transaction/WebDAV-request. Currently, resolve caching is not yet fully enabled (see doResolve method). I am still fighting with (a) performance drawbacks or (b) data inconsistencies when I fully enable resolve caching. 4) The UURI is currently generated in the class ResourceId. We thought that maybe the child store implementation should get an opportunity to determine the UURI policy? 5) Currently, with binding enabled, a filesystem-based content store maps to files where the filename is the resource-ID, e.g. 1072522837857.198_1.0. Here, an enhancement would be to map to the URI and take advantage of linking capabilities of the underlying filesystem. I wish you all a Happy New Year! Regards, Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
