Hi Oliver, I thinks you are right. Locking should be left to the child store implementation ... better, if possible, to the underlying database.
I created a new parent store called ResolvingStore by removing all related to t-locking from ParentStore. With the changes you checked-in for the TX store, tprocessor -pattern *cases\\functional* -users 4 -iterations 4 runs perfect. Only once I got a 500 from testcase functional\extra\multi-user\copy\copySame.xml ... but I couldn't reproduce is afterwards. Conclusion: apparently we do *not* need t-locks in the parent store as long as child store implementations support transtaction and certain level of isolation. BTW: as you noticed, our resolve implementation doesn't work correctly with multiple stores. We are working on that. Of course, we aim to support inter-store bindings. For now, to run the testsuite, what we do is that we define a single store matching "/" and let "/" have 3 subfolders: files, files_2 and files_secondCollection. So, as soon as I get this problem solved in ResolvingStore, I'll check it in and remove ParentStore together with the tlock package. Objections? Regards, Peter > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 06, 2004 16:03 > To: Slide Developers Mailing List > Subject: Re: T-Locking and Resolving > > > Inspired by the way deadlocks are handled in ParentStore, > file store now > throws a nested ConflictException upon deadlock. This way > deadlocks can > be resolved with response code "Conflict" passing multi user tests > copyDisjoint and copySame. It seems with this change t-locking is no > longer needed for the file store. > > It is worth noting there is no functional change in the file > store, the > only thing changed is the way this conflict is reported. > After all file > store really provides *SERIALIZABLE* as it's isolation level. > Thus there > never were any correctness issues with it. > > I am also almost done with the RDBMS port to binding and also applied > the same trick to it, so deadlocks are handled more > gracefully there as > well. I also added some framework (only reasonably implemented for > Sybase and MSSQLServer, yet) to handle contraint violations > that might > occur with low isolation levels like READ COMMITTED. > > All this raises the question if t-locks are still needed... Is it > *really* necessary for Tamino? > > 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]
