[smarlow]

Mark Little wrote:

The TM extension you mention would break compatibility and tie IronJacamar to Narayana. That's what I've been saying throughout this thread

IronJacamar would not have a direct dependency on Narayana, as that would be in WildFly integration code.  IronJacamar would need its delist workaround to be disabled in other integrations (which re-introduces the memory leak issue).  The IronJacamar delist workaround addressed https://developer.jboss.org/message/799730#799730.  I know very little of the memory leak issue, however, I do know about the havoc that the delist is causing.  We definitely need to avoid delisting resources before all of the other (not IronJacamar) Synchronization.beforeCompletions have been called so that the transaction includes all expected work. 

Linked the two forum threads together, in case that is helpful in the future.

Scott

[tomjenkinson]

Scott Marlow wrote:

Mark Little wrote:

The TM extension you mention would break compatibility and tie IronJacamar to Narayana. That's what I've been saying throughout this thread

IronJacamar would not have a direct dependency on Narayana, as that would be in WildFly integration code.

Hi Scott, what mark is saying is the it would still be a dependency on Narayana behaviour (i.e. the ability to order syncs). This is I believe why Mark is suggesting to try to get this in a standards body (sorry if I got you wrong here mark).

The workaround of disabling the delist resource call (just in the sync, not generally) should be OK with Narayana as it has code where by it will call the xa_end during prepare/commit if the resource was not delisted manually. This "ties" you in some ways to Narayana as other TMs may not do that for you but is available already today as a workaround should we wish to go down the standards route for sync ordering.

[marklittle]

Yes Tom, you're right. Whether it's IronJacamar or WF, adding this ordering behaviour to Narayana would then tie it to IJ/WF such that neither of them would be useable with other transaction manager implementations. Now maybe that's not a problem, but it's definitely a separate discussion that should be had before doing this!

I'll repeat something else I've said at least once already: using ordering as an OPTIMISATION is fine, but it needs to be just that - an optimisation. In order to remain compliant with the relevant standards and hence with other component implementations which are likewise compliant, WF/IJ should work correctly without this optimisation. They may not be as efficient (e.g., may be slower), but they must be correct.

[marklittle]

What's wrong with the dummy XAResource option I mentioned?

[marklittle]

Should I assume there's nothing wrong with my dummy XAResource suggestion and that's what IronJacamar will use instead ;-) ?

[jesper.pedersen]

Nah, WildFly will disable the delistResource() calls, and Narayana and the 3rd party resource managers will work their magic

[tomjenkinson]

So to confirm, we don't require the synchronization ordering for Narayana described in [JBTM-2259] Allow the ordering of some synchronizations to be configurable - JBoss Issue Tracker as Narayana will already perform any required XAR::end during prepare/commit instead of in the Synchronization? I thought the issue was related to the fact that synchronizations might use the jca backed resource in after completion (f.ex HHH and c.close()?) but if that is not an issue then I think we should close the Jira

[jesper.pedersen]

That JIRA should be used as a PoC for JTA.next.

Both the ordering of beforeCompletion and afterCompletion are needed. The work arounds to the issues are: WildFly disabling the delistResource calls in beforeCompletion, and IronJacamar killing the ManagedConnection if it detects a problem in afterCompletion.

[jesper.pedersen]

Well, Narayana doing the implicit call isn't apparently working in all situations. We can't mandate how 3rd party XAResources are implemented, and any internal state of associated Xid's.

IronJacamar calls transaction.enlistResource(xaResource), so IronJacamar must call transaction.delistResource(xaResource, flag) too. JTA_SPEC-3 lists not calling delistResource as a hack, but again we can't depend on certain XAResource implementation details. We have a case where other Synchronization objects depends on the XAResource still being enlisted when they are called - this requires an ordering not defined only by registerInterposed.

And not having the IronJacamar Synchronization afterCompletion being called last in all cases leads to the JCA ConnectionEventListener living past the transaction in which it was enlisted, as described by http://www.ironjacamar.org/doc/roadto12/txtracking.html, and thereby "granting" access to the underlying resource in a manner which the application / components using JCA doesn't expect. And, it is actually worse than that -- if the application / component never notifies the ConnectionEventListener past this point -> we have a connection leak.

This thread is how we are going to solve the hack described in JTA_SPEC-3, and the general problem of inter-dependencies of Synchronization objects at WildFly / EAP level.

[mmusgrov]

So it seems that the "workarounds" are not ideal:

• wildfly having to turn off all the IronJacamar extensions that check for application errors, since we don't have anything at EE level;
• the fact that it does not address the Oracle AMQ integration needs (I do not know what the particular issues here are);
• Marks suggestion about using Dummy XA resources is heavy weight (and would it help solve the AMQ integration).

How about the following plan of action to get things moving:

• implement the PoC as an extension that we can then submit to the JTA spec with a view to getting it standardized;
• in the meantime we add the extension to the transactions SPI and make it available for wildfly integration.

[jesper.pedersen]

Sounds like an idea -- it should be easy to find all the Synchronization implementations used inside an out-of-the-box WildFly setup, and analyze their inter-dependencies. As a PoC we could put IronJacamar last in all cases, as JCA is pretty low level

I think Scott have already analyzed the major JPA frameworks and their use --> very similar to Hibernate. He can confirm on that.

[tomjenkinson]

Jesper Pedersen wrote:

Well, Narayana doing the implicit call isn't apparently working in all situations. We can't mandate how 3rd party XAResources are implemented, and any internal state of associated Xid's.

Do you have an example of a case where it isn't working without a delistResource?  DelistResource is implemented by the transaction manager, the operations it invokes on the XAR during it we should be able to do during prepare so if there is a case we are missing we should get that raised as an enhancement:

https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L821

https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java#L210

[tomjenkinson]

Michael Musgrove wrote:

So it seems that the "workarounds" are not ideal:

• wildfly having to turn off all the IronJacamar extensions that check for application errors, since we don't have anything at EE level;
• the fact that it does not address the Oracle AMQ integration needs (I do not know what the particular issues here are);
• Marks suggestion about using Dummy XA resources is heavy weight (and would it help solve the AMQ integration).

How about the following plan of action to get things moving:

• implement the PoC as an extension that we can then submit to the JTA spec with a view to getting it standardized;
• in the meantime we add the extension to the transactions SPI and make it available for wildfly integration.

I think I missed something about AMQ, I tried to check the thread but I still can't see it?

What are you thinking about with regards the PoC? One route I can see working with SPI help might be as discussed here: https://java.net/jira/browse/JTA_SPEC-4?focusedCommentId=368214&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-368214. In that design the app server enlists a single Sync with the transaction and an SPI could be used to add other components syncs to its list which could be ordered.

What I still am not sure of is whether it should be considered legal for a synchronization to do c.close() in its afterCompletion (this is to address txtracking). Why can't the sync do c.close() in beforeCompletion?

[jesper.pedersen]

The original report of the missing IronJacamar delistResource call was JBJCA-1009 / JCA Spec violation using resource-adapter in JBoss 7?

So, any JBoss Application Server -- e.g. prior WildFly 8 -- the delistResource call would have been implicit by JBossTM / Narayana. Of course, it is disabled now too in WildFly through the IronJacamar hack. The question is if the call stacks between explicit and implicit are the same, given the same status flag.

The comment on JTA_SPEC-4 won't work. You can't ask all projects to add special cases for when they are running inside an application server w/ multiple Synchronization instances per transaction. You can only count on Synchronization instances being registered by

transaction.registerSynchronization(sync)
tsr.registerInterposedSynchronization(sync)

so the ordering solution will have to account for that. Yes, it is more a PITA for the application server, but the first PoC for Narayana could just be a "hardcoded" ordering (simple Comparator comes to mind) in the WildFly implementation of the SPI. The SPI should later be expanded to include an ordering definition "API" - depending on a Comparator implementation maybe enough, to be proven

I agree, that having c.close() in afterCompletion() isn't ideal, but luckily it is "only" a c.close() and no real work is performed - which would be outside of the scope of the transaction (well, du'h ). However, moving c.close() to beforeCompletion() doesn't solve the "delistResource" problem, "just" the return connection on transaction boundary one.

[marklittle]

Synchronizations in afterCompletion relying on XAResources still being registered with the transaction? Which ones? That is braindead - by the time the first Synchronization afterCompletion is called the transaction id "dead" and all XAResources could well have been garbage collected. This isn't an ordering issue, it's a broken implementation (of Synchronizations) issue!