5:58 a.m.
Hi,
Lately there was a need to fix a peculiar issue related to handling non-exiting tx: no
matter what results xa_commit would bring, it was ignored:
https://issues.jboss.org/browse/WFLY-7196
What I realised while working on it was this behaviour is kinda intentional. To be exact:
https://github.com/jbosstm/jboss-as/commit/87ea78a26a53b71411dd52753bb08e...
https://github.com/jbosstm/jboss-as/commit/de5fbd309cad0767eaf8cf9a8b55f8...
Making XidTransaction*Tasks more strict by throwing exceptions when there is no way to
find a transaction causes some test failures because the whole thing currently relies on
that.
We have sort of conflicting requirements here. I think we need to figure out how do we
distinguish between these two possibile situations when no tx is found: the one where we
call alarm and the one which we want to ignore.
Maybe that hack should be placed somewhere else. What do you think?
Fedor
8:14 a.m.
On 12/13/2016 05:58 AM, Fedor Gavrilov wrote:
Hi,
Lately there was a need to fix a peculiar issue related to handling non-exiting tx: no
matter what results xa_commit would bring, it was ignored:
https://issues.jboss.org/browse/WFLY-7196
What I realised while working on it was this behaviour is kinda intentional. To be
exact:
https://github.com/jbosstm/jboss-as/commit/87ea78a26a53b71411dd52753bb08e...
https://github.com/jbosstm/jboss-as/commit/de5fbd309cad0767eaf8cf9a8b55f8...
Making XidTransaction*Tasks more strict by throwing exceptions when there is no way to
find a transaction causes some test failures because the whole thing currently relies on
that.
We have sort of conflicting requirements here. I think we need to figure out how do we
distinguish between these two possibile situations when no tx is found: the one where we
call alarm and the one which we want to ignore.
Maybe that hack should be placed somewhere else. What do you think?
You are right, this needs to be examined.
In the UserTransaction case, the client clearly knows when no
invocations have taken place (as it will never have outflowed the
transaction) so it could just drop it. So this *should* be done on the
client side. Unfortunately we need the server side to remain for as
long as we have clients without this behavior.
In the XA case, it's a little more complex because the server might have
hosted invocations that it doesn't remember (due to new connections or
whatever). I don't think we can just ignore the transaction in *this*
case, but not doing so might cause other problems in this old code.
In EAP 7.1 I'm reworking some of this stuff (almost done in fact), but I
still have a couple of cases I have to figure out.
--
- DML
2939
days inactive
2939
days old
1 comments
2 participants
participants (2)
-
David M. Lloyd -
Fedor Gavrilov