Or, we could explain how to migrate from Slide 1.x to Slide 2.0. Isn't that easy using WebDAV COPY?
Regards, Peter > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 10:52 > To: Slide Developers Mailing List > Subject: Re: T-Locking and Resolving > > > There is one other thing that just reached my pea-sized brain: If we > change the XML representation of the file store - which is > necessary to > have binding - it will no longer be compatible to the old non-tx file > store. What to do about it? Just say, well that's the way it is, or > should we provide something like a compatibility mode? > > 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]
