JBAS-3321 - TransactionTimeout from EJB container

[adrian.brock]

The change done for this feature request is not correct.

The transaction timeout is not a property of the activation spec.
It is a property of the MDB container which is represented in JCA land
by the message endpoint factory (MEF).

What is required is a JBoss specific interface that the MEF implements
that allows you to retrieve the transaction timeout for a method,
i.e. similar to the isDeliveryTransacted(Method)

This then needs to be referenced from the MessageEndpointInterceptor.startTransaction()
method.
Of course if something else starts the transaction (like the server session)
is should also ask the MEF what the timeout is for the particular method.

[adrian.brock]

This goes back to what we discussed in Boston with the EJB3 team.

JCA should provide an abstract MessageEndpointFactory implementation
with "abstract" methods that containers can implement when they subclass.

The relevant callbacks would be:

// From the spec
public boolean isDeliveryTransacted(Method)
{
 return false;
}

// Get the transaction timeout (the subject of feature request)
public long getTransactionTimeout(Method)
{
 return 0l;
}

// Does the container provide a context classloader
// for switching during beforeDelivery
public ClassLoader getClassLoader()
{
 return null;
}

In practice there should be two implementations provided by JCA
1) That uses the old interceptors/proxy factory from EJB2
2) That uses the aop interceptors for EJB3 and POJO
The MessageEndpointInterceptor(s) for each would be maintained by the JCA project.

[weston.price]

The transaction timeout is not a property of the activation spec.

Why? I simply don't see the problem in the JMS/JCA adapter allowing for this.

It is a property of the MDB container which is represented in JCA land
by the message endpoint factory (MEF).

Again, why? There is simply nothing in the JCA spec to suggest this.

What is required is a JBoss specific interface that the MEF implements
that allows you to retrieve the transaction timeout for a method,
i.e. similar to the isDeliveryTransacted(Method)

So, instead of using the ActivationSpec, you use the MEF. The property is the same, you are just getting it from somewhere else. We have plenty of JBoss specific properties in our ActivationSpec, I see no need to subclass the MEF to simply pass as integer.

[adrian.brock]

Why?

Because your solution is not generic. It only works for the JBoss/JMS resource adapter.
And it only works for JMS because there is only one delivery method

javax.jms.MessageListener.onMessage(Message)

Put another way, your solution does not work in the following cases:
1) ActiveMQ's inbound resource adapter
2) Something that is not JMS
3) Something that has more than one delivery method in the listener interface.

To be generic, it must cater for the case where most inbound transactions
are started, this is in the MessageEndpoint, or more accurately in the
MessageEndpointInterceptor, the later being an implementation detail of JBoss.

It must also cater for inflow rars that have more than one listener method
or interfaces. That is why there is "java.lang.reflect.Method" on
the isDeliveryTransacted() callback.
The same should be true for the getTransactionTimeout() callback into the container.

[adrian.brock]

NOTE: I don't have a problem per se with there being a transaction timeout in the
ActivationSpec. But this is very specialised.

One example would be where the inbound rar does transaction inflow.
In that case, it could use the ActivationSpec to pass this parameter
to the ExecutionContext.setTransactionTimeout().

But in the above case, it is more likely that the transaction timeout config would be
coming from the same place as the inbound transaction?

[adrian.brock]

Of course, the getTransactionTimeout(Method) should really be on the spec
defined MessageEndpointFactory interface rather having to define your own
extension. But that's one for JCA2.0/JavaEE6 :-)

[weston.price]

Exactly. Every situation/scecnario you have posed is not relevant *right now*. The fix from the task simply allows for a transaction timeout for MDB's being that we are directly controlling the transaction demarcation which is not interceptor/AOP based (though I have a working version of this).

For the other scenarios (ActiveMQ, user inflow RARs), I am not sure this even makes sense being that

1) We have no control over this and a specialized MEF is really not applicable to ActiveMQ's implementation anyway. How exactly would this help ActiveMQ?

2) Same goes for other inbound RAR's that we do not control. How would a specialized MEF help this scenario? Do you expect them to case the MEF to a JBoss specific implementation and get the transaction timeout?

[adrian.brock]

The only transactions we don't control are the ones where we don't write the
rars and/or the rar starts the transaction before it hits the message endpoint.

The vast majority of inflow rars don't do this. With the exception of transaction inflow
there is no way for them to start a transaction, there's no spec defined integration
point to get the transaction manager.

They leave it to the container (message endpoint) to start the transaction from the ejb metadata. What they do is pass the XAResource to the MessageEndpoint
so they can take part in the transaction.
i.e. the XAResource is automatically enlisted in the transaction when the
beforeDelivery or "deliver" starts the transaction.

If we start the transaction, we should apply the configuration from jboss.xml
or the relevant ejb3 annotation.

If we start the transaction from our rars we should also use the same
integeration point, the message endpoint factory.

You asked before, why the message endpoint factory?
The answer is because that is the object in the JCA api that represents the
container and where different containers (EJB2, EJB3, POJO JCA)
can decide how the parameter is derived.

[adrian.brock]

i.e. the XAResource is automatically enlisted in the transaction when the
beforeDelivery or "deliver" starts the transaction.

We should also try to set the same timeout on the XAResource if it supports it.

[weston.price]

The vast majority of inflow rars don't do this. With the exception of transaction inflow
there is no way for them to start a transaction, there's no spec defined integration
point to get the transaction manager.

Correct. I hope to remedy this in JCA (1.6) ;-)

They leave it to the container (message endpoint) to start the transaction from the ejb metadata. What they do is pass the XAResource to the MessageEndpoint
so they can take part in the transaction.
i.e. the XAResource is automatically enlisted in the transaction when the
beforeDelivery or "deliver" starts the transaction.

Also, correct. Unfortunately, there are some JMS providers (that shall remain nameless) that will not work in this manner. So, we also have to have some way to allow for the timeout prior to the actual delivery of the message. This can easily be remedied with AOP which is probably the *right* way to do this anyway.

If we start the transaction, we should apply the configuration from jboss.xml
or the relevant ejb3 annotation.

This is what's in place now via the ActivationSpec. This was the point of the *fix*. You are simply proposing moving it to the MEF. I don't necessarily disagree with this I am simply wondering why.

The 'it's not generic' answer doesn't fly with me because the MEF solution isn't necessarily generic either. It's simply another way to achieve the same thing with the benefit that it can be leveraged by all inbound RARS that we write which has some merit, I agree.

[adrian.brock]

The 'it's not generic' answer doesn't fly with me because the MEF solution isn't necessarily generic either.

It's more generic than the current solution which only works for the JBoss inbound jms rar
and requires at least the two EJB containers to understand (hardwire) the ActivationSpec
format of that rar.

Given that the server project can't even reference connector classes
(circular dependency in the build) you'd either have to
1) Use reflection
2) Implement a proprietory interface in the activation spec

public interface TransactionTimeoutSetter
{
 void setTransactionTimeout(long timeout);
}

3) Annotate the property

@org.jboss.resource.annotation.TransactionTimeout
public void setTransactionTimeout(long timeout) {}

All of which is pretty ugly, given it only solves the problem for one usecase. :-)