[transaction] AbstractXAResource: prepare() with result XA_RDONLY without commit()

[Joerg Heinicke <jo...@gmx.de>]

I came across some further problems with the transactional FileResourceManager
and the XAResource implementation.

Simple deletes of resources did not get applied for me. Debugging showed that no
commit was triggered.

The reason: deleteResource() and createResource() in FileResourceManager were
assumed as being read-only (TransactionContext.readOnly not set to false). The
TransactionManager got XA_RDONLY as return value of XAResource.prepare() and so
did not trigger commit() or rollback(). The transaction in FileResourceManager
remains in uncompleted state. I'm going to commit a fix for this problem.

Second problem is the prepare() with result XA_RDONLY without commit(). I assume
it is a bug in AbstractXAResource too, but maybe somebody can confirm it first.
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. WDYT?

Regards,

Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource: prepare() with result XA_RDONLY without commit()

[Joerg Heinicke <jo...@gmx.de>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource: prepare() with result XA_RDONLY without commit()

[Oliver Zeigermann <ol...@gmail.com>]

2006/6/22, Joerg Heinicke <jo...@gmx.de>:
> I came across some further problems with the transactional FileResourceManager
> and the XAResource implementation.
>
> Simple deletes of resources did not get applied for me. Debugging showed that no
> commit was triggered.
>
> The reason: deleteResource() and createResource() in FileResourceManager were
> assumed as being read-only (TransactionContext.readOnly not set to false). The
> TransactionManager got XA_RDONLY as return value of XAResource.prepare() and so
> did not trigger commit() or rollback(). The transaction in FileResourceManager
> remains in uncompleted state. I'm going to commit a fix for this problem.

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?

> Second problem is the prepare() with result XA_RDONLY without commit(). I assume
> it is a bug in AbstractXAResource too, but maybe somebody can confirm it first.
> 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. WDYT?

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?

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org