It's in doResolve. This method locks all parent folders and the resource itself. The actual locking is done by the tlockManager.lock(currentResourceId, currentUriStr, lockType); calls.
You're right - doTLock is never called. I suspect Peter has moved the code into doResolve and forgot to delete the old method ... Michael On Tue, 2004-01-06 at 13:29, Oliver Zeigermann wrote: > I may have missed something, but in ParentStore I found no evidence > anything is locked when objects are stored or removed. Maybe doTLock in > was intended for this, but is never used... > > Could someone explain thit to me, please? > > Thanks, > > Oliver > > > Nevermann, Dr., Peter wrote: > > > 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] > > > > > > . > > > > > > > --------------------------------------------------------------------- > 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]
