I will try and recall the exact flow of this from when we did the testing on this problem, but anyone can correct me if I have recalled things incorrectly, or have miss-understood.
The core issue is that if you are using a both the descriptors and content stores then a single slide transaction spans inserts/updates across both stores, but a db transaction is only within a single store. This creates an issue since the connections cannot be shared across both stores (as they are created inside the individual stores), so if you have an incomplete 'PUT' and need to rollback then the database can be left in a bad state, or if you are reading and writing the same file from two different threads then you can get a bad read, or if you have two threads adding files and they both try to add a directory at the same time, all these can lead to DB contention or integrity issues. In addition the core problem we saw was database contention when you do two writes from separate slide operations at the same time you can get contentions with two transaction stuck waiting for locks to release. Ashok has some test cases for this which he can post. We are running slide in a mode where we have hundreds of files being updated, while the same files may be trying to be read. This was locking the DB. So by using the slide transaction ID as the key for the XA datasource you keep the same DB transaction alive for the whole slide transaction, and make sure that contention does not occur. This behavior could be changed by making the connection at a higher level than the store, but the current slide architecture does not appear to make this easy. I believe all the above is correct, but I am open to other ideas. rgds CB ----- Original Message ----- From: "Christopher Lenz" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Friday, August 09, 2002 5:01 PM Subject: Re: New J2EE stores: subselects > Colin, > > Colin Britton wrote: > > Does commons-DBCP support XA datasources? I didnt think it did. We are using > > Tyrex 1.0 with TC 4.1.7 (or 8) > > I guess I am somewhat confused about XA... > > In a previous mail, you stated: > > >The J2EE stores REQUIRE an XA datasource, this is because the slide > >transactions are across multiple database transactions. > > I've not been very deeply involved in the backend side of slide (stores > & transactions) yet, but I was under the impression that while slide > transactions could span multiple methods of multiple stores, they would > never span multiple threads. For instance the loading of the namespace > base data at bootstrap should be in one thread (e.g. the servlet.init() > thread), and all transactions through the WebDAV access layer should > happen in the thread of the particular HTTP request/response cycle. > > If this assumption is correct, then using a simple datasource or > connection pool should suffice, as long as only one instance of Slide is > accessing it at any one time. > > But you seem to imply that my assumption is incorrect... > > Maybe you (or someone else) can enlighten me :o) > > -- > Christopher Lenz > /=/ cmlenz at gmx.de > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
