Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes: > > The reason: deleteResource() and createResource() in FileResourceManager > > were assumed as being read-only (TransactionContext.readOnly not set to > > false). > > Hard to believe, but this really seems to be true. A fix should be > simple, right? Will you do that. I wonder why this hasn't shown > before?
The fix is hopefully as simple as I did it. I tested it at least using that patch and got my symptoms fixed (read below). Why it hasn't shown before? Good question. What I can imagine - at least for createResource() - is that nobody actually just uses createResource() but also writeResource(). If nobody has ever used a simple single deleteResource() as I do it does not bubble up. I would really like to add such things as test cases but I'm unfortunately really short on time at the moment. > > There is no clear comment about it in the spec. Only the API for XAResource > > says for XA_RDONLY: "The transaction branch has been read-only and has been > > committed." That is probably why the TransactionManager did not trigger a > > commit() on prepare() with XA_RDONLY. > > Yes, I think when the result is XA_RDONLY there is no need for a > commit, as there is nothing to commit. I just wonder when the > transaction is ended. When are the read locks set free? The problem is that these resources were never freed. And I observed it just by some symptoms: In my work dir more and more directories got added but not freed after the "end" of the transaction. The transaction simply did not end. With fixing read-only status of deleteResource() and createResource() I got at least lower growth-rate of directories, but real read-only operations did still end in remaining directories. I added a quick fix checking for XA_RDONLY in AbstractXAResource.prepare() and committing in case of. It might not be really appropriate, but had no other short-term solution. And I do not really know if the immediate release of resources in FileResourceManager.prepare() in case of read-only status is more appropriate as the specific transaction management (no commit() when prepare() returns read-only) comes from JTA. OTOH why should other transaction management implementations behave differently when there are well-known basics. Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
