I don't understand why doResolve skips locking if the resourceId is found in the cache!
In my optionen, we have to lock in either case because we cannot be sure that to resolve call that filled the cache was performed with the same lock type we got in the current doResolve. For example: the first doResolve might request lock type "READ_LOCK", but the second call might request lock type WRITE_LOCK. In this case, the first call fills the cache and obtains read locks, but the second call does *not* obtain write locks!? I'm not really happy with all this caching ... I'd love to see resourceIds used in the slide layer - we could beform a single resolve there and always call stores with resourceIds later. This would make the cache obsolete. But that's a major change ... 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]
