[marklittle]

Hold on ... which POC implementation?

[marklittle]

Let's step back a bit here. Maybe I'm missing something but your idea of a POC seems more like a hack to get around problems that some Synchronization implementations have in their assumptions about what is and is not legal with XAResources once the transaction is terminated. Furthermore, everyone should also remember that calls to afterCompletion are essentially "nice to have" and some transaction implementations (not ours) can fail to run them in some circumstances because they don't affect the outcome of the transaction anyway.

[marklittle]

BTW where do you get the idea that a dummy XAResource is "heavy weight"?

[marklittle]

"implement the PoC as an extension that we can then submit to the JTA spec with a view to getting it standardised;"

The first step to doing anything like this has to be to articulate the problem statement well and as a result show why existing options are not going to succeed. I've yet to see any of this come together. That needs to be the first step before anything (including POC) is done.

[tomjenkinson]

For myself the issue that I think we are trying to address here is when IronJacamar can safely call delistResource. WRT to the afterCompletion thing, I personally think that if someone is holding onto the connection till aC then that is a bug and IJ is right to report it as such whether it is called first or last and so ordering in afterCompletion is not required.

The problem as I understand it:

Q. What is the problem with IronJacamar calling delistResource when it is in a random ordered interposed synchronization list?

A. If IJ is the first sync, it is not safe as it will delist the resource then the JPA flush will be outside of the transaction.

So it seems like the options are:

1. Impose ordering and get IJ beforeCompletion called last so it can safely do a delistResource

2. Avoid ordering issues by getting IJ not to call delistResource and leave it to Narayana to do the end

Option 2 is fine (assuming no bugs in Narayana) except if someone replaces the transaction manager and that TM requires delistResource to be called. Currently I believe delistResource is being disabled by IJ so this is in effect the option we are running with today. Ideally the TM would replaceable and so it would be nice for IJ to be able to call delistResource.

I think the simplest way to achieve this is for WildFly to provide its own TransactionSynchronizationRegistryImpl and therefore this requires no changes to Narayana. As we only need to order interposed Syncs the WFLY implementation can delegate all calls back to the Narayana impl except registerInterposedSync. That would have an implementation like this and reside in the WildFly repo:

public class TomsTransactionSynchronizationRegistryImple extends
          TransactionSynchronizationRegistryImple {

     @Override
     public void registerInterposedSynchronization(
               Synchronization synchronization) {

          OrderedSync resource = (OrderedSync) getResource("orderedSync");
          if (resource == null) {
               resource = new OrderedSync();
               super.registerInterposedSynchronization(resource);
               putResource("orderedSync", resource);
          }
          resource.add(synchronization);
     }

     private class OrderedSync implements Synchronization {

          private List list = new ArrayList();

          public void add(Synchronization synchronization) {
               // TODO add in the right position based on classname or whatever
               list.add(synchronization);
          }

          @Override
          public void afterCompletion(int arg0) {
               for (Synchronization synchronization : list) {
                    synchronization.afterCompletion(arg0);
               }
          }

          @Override
          public void beforeCompletion() {
               for (Synchronization synchronization : list) {
                    synchronization.beforeCompletion();
               }
          }
     }
}

This should affect other application servers too (the delistResource predicament) - hence why we are talking JTA spec though I guess as the issue is around app server integration it may not be deemed suitable for standardisation.

[mmusgrov]

Mark Little wrote:

Hold on ... which POC implementation?

I implemented the PoC early on before we got into the discussion about whether it was the correct approach (JBTM-2259).

Mark Little wrote:

BTW where do you get the idea that a dummy XAResource is "heavy weight"?

Maybe heavy weight was unfair but I was picking up on your comment about using the approach when you said:

"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!"

Tom's just posted a solution which sidesteps most of these issues so the PoC is probably not be required after all.

[jesper.pedersen]

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.

[tomjenkinson]

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.

Sure, but do we have a scenario we are aware of where registerSync needs ordering? I thought at the moment we only have an issue with JPA, (possibly) HQ, HHH and IJ sync ordering and they all use interposed as far as I can tell?

[jesper.pedersen]

WildFly doesn't suffer from this, but it is basically the same problem as interposed that needs solving - 2 birds with 1 stone

[tomjenkinson]

If I read the thread right we are not actually getting any users coming to us and asking for us to solve the problem of ordering none-interposed syncs. On the other hand we do have a community of users who I think would really appreciate us solving the interposed sync ordering issue

It might be useful to provide a facility to order none-interposed syncs, but without an actual customer request or use case for the feature its hard to recommend designing a feature for the perceived need versus just cut-and-pasting comment 49 into a WFLY pull request

[smarlow]

Mark Little wrote:

BTW where do you get the idea that a dummy XAResource is "heavy weight"?

The dummy XAResource idea sounds heavy weight on performance, in its initial suggested form (until optimisations are introduced):

"

"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.

"

[marklittle]

When I referred to the "ant" I was talking about the entire thread and proposals, not one specific aspect

The XAResource option (2PC participant) shouldn't be any more heavy weight than adding another Synchronisation - you just get the guaranteed ordering before Synchronizations. The implementation doesn't have to do anything transactional or with a database in any of the methods and we wouldn't even have to save it to the intentions list.

[marklittle]

Agreed, at least from my reading of this thread too.

[jesper.pedersen]

The 3 test cases for this thread should something like

Consumer 
-------- 
  beforeCompletion 
     if (!isEnlisted(xaResource)) 
        throw new RuntimeException(); 

  afterCompletion 
     if (sharedResource == null) 
        throw new RuntimeException 

Owner 
-------- 
  beforeCompletion 
     delistResource(xaResource) 

  afterCompletion 
     sharedResource = null; 

with the following registration order

1. C1, C2, O
2. C1, O, C2
3. O, C1, C2

All registration orders has to pass, and it is clear that the owner has to run last no matter the registration order. Similar test cases for non-interposed could be implemented.

[marklittle]

I think the example is a little too pseudo and not enough code

Can you explain what are C1, C2 and O? What are their relationships? What's a "shared resource"? What is the use case that you're trying to address?

Rather than throw out an example based upon what is implemented today, let's look at this objectively and consider the problem first and foremost. It may well be that the answer ends up being precisely what you have outlined. But let's not start from that position in case it causes us to ignore alternatives.