commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [transaction] AbstractXAResource: prepare() with result XA_RDONLY without commit()
Date Thu, 22 Jun 2006 23:27:31 GMT
Oliver Zeigermann <oliver.zeigermann <at>> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message