10 Replies Latest reply on Feb 9, 2007 10:51 AM by Adrian Brock

    JBAS-3321 - TransactionTimeout from EJB container

    Adrian Brock Master

      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.

        • 1. Re: JBAS-3321 - TransactionTimeout from EJB container
          Adrian Brock Master

          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.

          • 2. Re: JBAS-3321 - TransactionTimeout from EJB container
            Weston M. Price Master

             


            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.



            • 3. Re: JBAS-3321 - TransactionTimeout from EJB container
              Adrian Brock Master

               

              "weston.price@jboss.com" wrote:

              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.

              • 4. Re: JBAS-3321 - TransactionTimeout from EJB container
                Adrian Brock Master

                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?

                • 5. Re: JBAS-3321 - TransactionTimeout from EJB container
                  Adrian Brock Master

                  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 :-)

                  • 6. Re: JBAS-3321 - TransactionTimeout from EJB container
                    Weston M. Price Master

                    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?

                    • 7. Re: JBAS-3321 - TransactionTimeout from EJB container
                      Adrian Brock Master

                      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.

                      • 8. Re: JBAS-3321 - TransactionTimeout from EJB container
                        Adrian Brock Master

                         

                        "adrian@jboss.org" wrote:

                        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.

                        • 9. Re: JBAS-3321 - TransactionTimeout from EJB container
                          Weston M. Price Master

                           


                          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.



                          • 10. Re: JBAS-3321 - TransactionTimeout from EJB container
                            Adrian Brock Master

                             

                            "weston.price@jboss.com" wrote:

                            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. :-)