JBossDeveloper

Nice try, but I won't write the test cases But I'll give you a bit more

XAResource xares = new MyXAResource();
tm.begin();
tx = tm.getTransaction();

Owner o = new Owner(tx, xares);
Consumer c1 = new Consumer(xares);
Consumer c2 = new Consumer(xares);

tsr.registerInterposed(o);
tsr.registerInterposed(c1);
tsr.registerInterposed(c2);

Owner(Transaction, XAResource)
  tx.enlistResource(xares);
  SharedResource.getInstance().setValue(whatever);

The XAResource represents the associated XAResource for a JCA ManagedConnection -- the shared resource represents a JDBC connection handle. So, think of 'Owner' as JCA, C1 as a JPA PersistenceUnit and likewise for C2.

We need to keep the XAResource enlisted in the transaction until all consumers are done (beforeCompletion), and return the connection handles (afterCompletion) such that 'Owner' can set to null -- in this case; real world, return to pool.

If the IronJacamar hacks are disabled in WildFly, scenario 2 and 3 will pop up at once.

I'm not asking you to write a test case - the complete opposite actually because I think a test case only tests what you currently believe is a valid scenario. What I'm asking for is a complete and objective description of the problem statement. No code involved at all. The description you've given is still making reference to the particular situation we find ourselves in today - that's an implementation detail. Step back and look at this in the abstract if necessary.

Maybe a forum isn't the right medium to get to the bottom of this.

Hi folks,

Based on our discussions in Brno I have now prototyped a solution that will work for any transactions implementation in WildFly.

Before I present the solution, I will clarify the two problems that are solved. Both of these problems relate to how to handle the fact that various components (such as JPA) register interposed synchronizations which need ordering prior to the JCA interposed synchronizations.

The before completion issue:

JCA beforeCompletion() { // Jesper tells me this has to be interposed

tm.delistResource(JPAdatasource) // Jesper says this has to be done as part of JCA spec

}

JPA beforeCompletion() { // Scott tells me this has to be interposed

flushToDataSource() // This is allowed and is the intuitive way to implement JPA

}

The after completion issue:

JPA afterCompletion() {

connection.close()

}

JCA afterCompletion() {

if (!connection.closed())

// log error

}

Those two examples show strong ordering within the app server for two interposed Synchronizations.

My solution tackles those issues directly. It does not deal with any further ordering issues and defers that to future revisions of the JTA spec. My solution is purely in WFLY code and does not affect Narayana code so if you are running external to WFLY the issue still exists. The before completion current workaround (allowing Narayana to call delistResource) works outside of the app server, the after completion issue would need a similar solution to the proposed one applying.

Without further ado: Comparing wildfly:master...tomjenkinson:wrappedTSR · wildfly/wildfly · GitHub

You can see that the Synchronizations are not registered directly with Narayana but with an intermediary instead. Having reviewed the Narayana local and JTS variants this should not be an issue today but note the caveat in my solution that if in the future we tried to overload the registerInterposedSynchronization method and perform instanceof on the Synchronizations or some other form of computation on them the solution would not work. I would think therefore it might be prudent to modify the solution to only include JCA and JPA in the new lists and delegate all other interposed synchronizations down to Narayana. The advantage of including them all in the list is that other frameworks that rely on JCA will automatically benefit from this ordering (HHH and HQ I am thinking of as possibly being affected by the issues described above).

Tom

The

interposedSyncs.remove(tx);

will only work in JTA scenarios, as 'tx' isn't stable over time (e.g. inside afterCompletion) for JTS. Hence you need a fallback for an == scan. Similar hack ironjacamar/TransactionSynchronizer.java at 1.2 · ironjacamar/ironjacamar · GitHub

Remember to remove wildfly/JcaExtension.java at master · wildfly/wildfly · GitHub before testing.

Thanks for the tip-off, Jesper - much appreciated. I have updated the diff with your observations. I have an external unit test that seems to show my TSR in action and the JPA/JCA ordering in place but JPA seems to always be registered first anyway so its difficult to test. Do you know if the issue was intermittent or is there a reliable way to trigger the scenario?

Use straight JDBC before invoking JPA - e.g. Connection c = ds.getConnection(); yada-yada; c.close(); JPA yada-yada

Perfect - thanks Jesper! It means I do have a standalone EJB test that proves this approach works.

One thing I am not seeing is any warning if I don't close the connection. Is there something else I need to disable to get the warnings back on for connection leaks? Here is my test:

        Connection connection = datasource.getConnection();

        entityManager.persist(new TestEntity());

        // connection.close();

The EM is using the same datasource, maybe that is the reason I don't get the warning as it may be closing the connection, but I thought that JCA might expect a .close() per .getConnection()

Using tracking=true will make it scream... Assuming you are inside a transaction... WildFly doesn't make use of IronJacamar's tracking feature by default. Further details at http://www.ironjacamar.org/doc/roadto12/txtracking.html

Perfect - thanks Jesper. It all seems to be working just fine now then. I will go ahead and raise a PR on WFLY.

Thanks all for the input.

Jesper Pedersen wrote:

 

Having a TSR extension solves the "tsr.registerInterposedSynchronization(sync)" case, but not the "transaction.registerSynchronization(sync)" case.

 

Currently the delistResource call has to be implicit by the TM when running inside an environment where multiple Synchronization objects are registered which has implicit interdependencies - such as JDBC|EJB|JPA|JMS|... depending on JCA. However, the delistResource method is part of the official JTA API, and must be called by the enlisting component. Everything else is considered a hack by JTA_SPEC-3.

As Tom pointed out on the following comment we do not have a use case for ordering session synchronizations. Now, since we have solved the requested use case in WFLY-361 (the transaction subsystem provides a specialized TSR that orders JCA synchs such that they are ran after all other synchs) there is no longer any immediate requirement to support synch ordering within narayana ([JBTM-2259] Allow the ordering of some synchronizations to be configurable - JBoss Issue Tracker).

Are there any objections to me rejecting JBTM-2259?