[wildfly-dev] 4 y.o. transactions hack calls wildfly his home now: should we depart it?

[David M. Lloyd]

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/87ea78a26a53b71411dd52753bb08ef06a8e5969
> https://github.com/jbosstm/jboss-as/commit/de5fbd309cad0767eaf8cf9a8b55f89a7092fdf4
>
> 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