> Yes something like that is needed but wait a bit before implementing it. > > I'm still not sure how the J2EE store works. > Do you know if the J2EE store is working correctly and why ? > > 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. > > In the current implementation, there is only one Connection object and > that connection object is used in all threads (for all concurrect > requests/transactions). I always had the impression that you had to get > a separate connection for each concurrent transaction. Another > possebility is that the transaction manager does some magic behind the > screens but we are not using a XAConnection, are we? (I don't see the > code for this). > > Ashok, Remy or somebody else can you explain how this J2EE store does > its transaction management?
Your analysis is accurate. More specifically, we should have a hashtable of active connections keyed by the global transaction id (add them to the hash when doing the first start, and remove them when committing or rolling back the transaction). That's how I was planning to implement it originally, anyway. Here, as you said, the connection object gets used simultaneously in different transactions, which may indeed cause the problems with dirty reads (of course, it's rather hard to predict). Using a XAConnection doesn't add anything here. It just means you could enlist it directly in the transaction, but it doesn't work like that in the Slide model (since we enlist the store which hides a lot of the operations done on the connection). Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
