jakarta-slide-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nevermann, Dr., Peter" <Peter.Neverm...@softwareag.com>
Subject Are t-locks needed? was: RE: T-Locking and Resolving
Date Tue, 06 Jan 2004 17:20:30 GMT
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:ozeigermann@apache.org]
> 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: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> > 
> > 
> > .
> > 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


Mime
View raw message