> I'm still not sure how the J2EE store works. > Do you know if the J2EE store is working correctly and why ?
>From the tests we have done I think the store is working fine, but I am not sure about how locking works. Certainly the tests of multi-user put's and get's of different URL's have not shown any problems. The only issue has been this GET/PUT combination. > > I think something is missing in the store implementation and that's why > you also get those wrong content lengths that you reported in your mail > "Problem with GET and content Length". A second user sees the new > content length before it is committed. > The situation is that the second user is given the OLD content length and then made to wait for the PUT to complete before getting the content. I don't yet understand how the transaction locks work but the second users GET definitely reads the old descriptor value for content length, because the new content length is not added till the PUT completes. And tests of specific size files have proved this. It would seem (although I don't know) that the locking is independent between the descriptor store and the content store. and certainly a GET is not stopped from the reading the descriptor store for a given url/revision while its content is being changed. I need to understand this piece a bit more fully. In order to make it more synchronous updating content should create a new revision and then remove the old revision. This would prevent any overlap problems of data in the descriptors store and content stores being out of sync temporarily and would also allow synchronous GET's of content. In our application we are continually updating files underneath another application that is reading them, it is a problem for us that a resource temporality unavailable when it is deleted as part of the update and it would be advantages if a GET at worst got the old content, if the new content had not finished being updated - which can take a few seconds for a large file. I need to work out where this work could be done as it would need to occur across both stores. ideas? comments? I am quite prepared to admit I don't understand enough about all the internals of slide but need to solve this. > In the current implementation, there is only one Connection object and > that connection object is used in all threads (for all concurrent > requests/transactions). With the J2EE store it is abstracted from AbstractService which can have multiple concurrent transactions. Each transaction is the context name (this is the same as the store name I think) and for AbstractService it also uses the current thread, so you can have one instance of the service per thread. In abstractSimpleService it is one instance of the context (store?) at a time. The J2EE datasource configured in Tomcat uses a lazy pool and hands out (and creates) as many objects as are needed and shrinks when they are not used. I believe it also tests if they are still valid as well, but I am not sure on that point (would need to look at tyrex - the pool implementation, again to remember). The connection is not tied into the transaction as far as I know. Remy might be able to explain this some more but this is my understanding. rgds CB -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
