Quantcast

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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Fedor Gavrilov
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?

Fedor
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...