[tomjenkinson]

Jesper Pedersen wrote:

In addition to sorting based on class names I think add package names too. That way it is up to each project to maintain their own internal sorting, and it makes it easier to configure -- "*, org.hibernate, org.jboss.jca"

+1

[marklittle]

See my comment on the JIRA. I'm not convinced this is the right approach as it breaks interoperability.

[marklittle]

Hold on guys. I said we *could* do ordering of Synchronizations but I didn't say we should do it! What happens when/if IronJacamar is used stand-alone and with some other transaction manager which is also JTA compliant? IronJacamar is not not JCA compliant AFAICT if it requires a specific ordering of Synchronizations. There are ways of approaching this which are spec compliant: I mentioned one, which is using an XAResource instead of a Synchronization if necessary.

[mmusgrov]

Mark Little wrote (in a comment on the JIRA):

OK, but this is not compliant with the standards and therefore if some other transaction engine is used it will break. The reason ordering of resources and synchronisations isn't supported in the standards is because it becomes very hard to manage global ordering in a heterogenous environment. Are we really happy to add something which basically ties IronJacamar and Narayana together? I'm no so sure. While it's nice to add something like resource ordering, as we do with AbstractRecords, it should be done cautiously, in situations where no other option is possible, or as an optimisation, i.e., so without it the system still works, but may be slower, less efficient etc.

The standard only specifies that interposed Synchronizations should be called after all SessionSynchronizations - it leaves it up to the implementer to decide how to order Synchronizations within either of these 2 groups. Therefore code that expects a particular order is unlikely to see the same behaviour on two different app servers. The proposal is to allow the ordering to be changed within either of these two groups so there is no question of breaking spec compliance.

[mmusgrov]

mmusgrov wrote:

Mark Little wrote (in a comment on the JIRA):

OK, but this is not compliant with the standards and therefore if some other transaction engine is used it will break. The reason ordering of resources and synchronisations isn't supported in the standards is because it becomes very hard to manage global ordering in a heterogenous environment. Are we really happy to add something which basically ties IronJacamar and Narayana together? I'm no so sure. While it's nice to add something like resource ordering, as we do with AbstractRecords, it should be done cautiously, in situations where no other option is possible, or as an optimisation, i.e., so without it the system still works, but may be slower, less efficient etc.

The standard only specifies that interposed Synchronizations should be called after all SessionSynchronizations - it leaves it up to the implementer to decide how to order Synchronizations within either of these 2 groups. Therefore code that expects a particular order is unlikely to see the same behaviour on two different app servers. The proposal is to allow the ordering to be changed within either of these two groups so there is no question of breaking spec compliance.

Ah I see what you mean - IJ and JPA should not be reliant on a specific ordering since different JTA implementations may do it differently. The only proposal on the table that doesn't rely on the ordering of synchronizations that I have seen in this thread is for one of them to become the last participant but that solution also suffers from a standards perspective since there is no standard way of ensuring a participant is the last participant in the intentions list.

[jesper.pedersen]

The "problem" is that IronJacamar is spec compliant by calling delistResource(xar, flag). This happens in a beforeCompletion, which is the last possible time to make the call.

Since there is no well-defined order of how the interposed Synchronization instances are run -- apart from registration order -- a Hibernate Synchronization instance may run after and depend on an enlisted XAResource instance.

IronJacamar now has a system property which disable the call to delistResource(xar, flag) -- hence only enlistResource(xar) is called -- which works around the problem for Hibernate. However, it is now up to transaction manager implementations, and 3rd party XAResource implementations to do the right thing in all cases.

Especially, one 3rd party vendor comes to mind where they make all sort of assumptions inside their XAResource implementations causing massive memory leaks. But, I'll give them a chance to fix their code

[marklittle]

Mike, this does break spec compliance. Even looking at a specific Synchronization implementation (class), nowhere in the specifications does it say that instance X should be before instance Y. Or class X before class Y (ignoring interposition for now). The same is true for XAResources. Any implementation that only works because it assumes a specific ordering is not spec compliant.

[marklittle]

Yes, your understanding is correct.

[marklittle]

So there is an approach that does not require the ordering change? If so that's great, even if it imposes more overhead on the user or TM. But can you clarify?

I've always said that ordering is a good thing (that's why we have it with AbstractRecords for 30 years). But there hasn't been enough industry support to push this into a standard. Maybe now is the time to try to propose this again.

[tomjenkinson]

Hi Jesper,

I thought that the issue was not just delistResource, it was also for you to close the JBDC connection?

Tom

[jesper.pedersen]

It is not a problem for IronJacamar to close the ManagedConnection in afterCompletion It may be a problem for services using JCA backed resources in their afterCompletion, if they are run after the IJ Synchronization.

[tomjenkinson]

Are we aware of any such services that use the connection in afterCompletion? - I would imagine this would contravene some spec or another - they certainly shouldn't be piping SQL/messages down it with the expectation of it being part of the current transaction.

[marklittle]

Agreed. The transaction has terminated by the time afterCompletion is called and nothing transactional done within that method affects the transaction outcome or can happen within the scope of the original transaction.

[smarlow]

Ah I see what you mean - IJ and JPA should not be reliant on a specific ordering since different JTA implementations may do it differently. The only proposal on the table that doesn't rely on the ordering of synchronizations that I have seen in this thread is for one of them to become the last participant but that solution also suffers from a standards perspective since there is no standard way of ensuring a participant is the last participant in the intentions list.

The IJ memory leak workaround (delist during beforeCompletion) is the code change, that introduced an ordering dependency (any JPA activity that occurs after delist is doomed to be isolated from the transaction).

Without the synchronization ordering (extension), we cannot *use* the current IJ workaround for the memory leak.  I do not know anything about the actual memory leak that is worked around with the delist.  Is that possible to fix or is it by design?  If the memory leak cannot be fixed for some reason, we should consider allowing the delist fix.

Another way to do the delist, would be to have IJ auto register (with a TM extension) that the delist should be performed after the last Synchronization.beforeCompletion callback is called.

[marklittle]

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

If something really needs to be run after the last beforeCompletion then why can't IronJacamar add a dummy XAResource (doesn't need to do recovery, persistence etc.) that does this in the prepare phase? Yes that potentially blows away any 1PC optimisation (assuming there was only a single resource in the transaction), but if we ignore that for now and this approach works then we can look at optimisations such as ordering that are used in the presence of Narayana, using the sub-optimal (but correct) XAResource approach in the case where it's some other transaction manager.

However, this all seems like a lot of work to fix a memory leak. Kind of like trying to kill an ant with an atom bomb!