1 2 Previous Next 15 Replies Latest reply on Feb 23, 2007 10:48 AM by Adrian Brock

    JCA antipattern? Or not?

    Tim Fox Master

      Hello all-

      I was interested in the JCA opinion on the following:

      If I am using a straight JMS connection factory (no JCA) then the following code done in a tight loop is clearly an antipattern:

      :begin
      
      Connection conn = cf.createConnection();
      
      Session sess = conn.createSession(...);
      
      MessageProducer prod = sess.createProducer();
      
      prod.send(sess.createMessage()));
      
      conn.close();
      
      loop begin
      


      Since it will be creating a new connection, session etc for every message sent which would be incredibly slow.

      However when using JCA the above becomes the "recommended" pattern of usage from within a managed environment (ejb/servlet/mbean) since JCA caches the connection and session so new ones don't actually necessarily get created.

      Ok, this is all pretty basic stuff.

      But what about the following:

      :begin
      
      Connection conn = cf.createConnection();
      
      Session sess = conn.createSession(...);
      
      MessageConsumer cons= sess.createConsumer(...);
      
      Message m = cons.receive(1000);
      
      conn.close();
      
      loop begin
      
      


      For straight JMS the above would again be clearly an antipattern.

      But what about JCA? It's my understanding that JCA does not cache jms consumers so every call to createConsumer() in the above is going to result in a new consumer being created on the jms provider. I.e. a heavyweight operation.

      Would you consider the above to be an antipattern when using JCA? (I.e. using a managed cf)

      If users want to receive a JMS message in the context of a distributed transaction using JCA1.5, then what is the recommended way of doing this?



        • 1. Re: JCA antipattern? Or not?
          Weston M. Price Master

           


          If users want to receive a JMS message in the context of a distributed transaction using JCA1.5, then what is the recommended way of doing this?


          Use a JCA 1.5 JMS resource adapter to manage the inflow. This is one of the primary use cases for our JMS/JCA resource adapter. The adapter itself simply leverages the ASF facilities under the hood to accomplish this in a manner consistent with JCA (ie ActivationSpec, ConnectionConsumer etc).



          • 2. Re: JCA antipattern? Or not?
            Tim Fox Master

            Good - this is exactly what I was hoping you would say. :)

            The interesting thing is this case arose because a user is using Spring with jboss messaging, and it seems the Spring JMS template is doing ugly things like the antipattern in the previous post when receiving messages. :(

            (Another reason for not using spring I guess.)

            BTW is there much doco about using jca jms resource adapter to do this from an MBean? They are not using mdbs.

            Thanks

            • 3. Re: JCA antipattern? Or not?
              Weston M. Price Master

               


              BTW is there much doco about using jca jms resource adapter to do this from an MBean? They are not using mdbs.


              The JMS RA is targeted towards message endpoint deployments. Today, it requires MDB's to function correctly. Basically the JMS/JCA RA takes the place of the JMSContainerInvoker in JBoss 3.x and early version of JBoss 4.x.

              I would be willing to bet the lionshare of the problem with the Spring example is the use of non ASF facilities in application server environment to 'simulate' MDB type semantics using a 'poll' type mechanism for delivery (ie cons.receive()) rather than the ASF ConnectionConsumer wherein the provider is responsible for 'pushing' messages. There is nothing to prevent them from using ASF in their own code, but I would be willing to bet the Spring stuff does not which is causing problems.

              Since what they want is non standard and outside the purview of both the JCA and JMS/ASF spec they would have to develop a custom RA to do this.




              • 4. Re: JCA antipattern? Or not?
                Tim Fox Master

                Understood that this would be outside the JEE specs, but still quite useful IMHO.

                I believe projects like Jencks already support this kind of thing http://jencks.org/Message+Driven+POJOs. This would allow people to leverage JCA more fully for message inflow in a managed environment without using any EJB (MDB) stuff.


                Any plans of doing something like this? Or is it not on the radar?

                • 5. Re: JCA antipattern? Or not?
                  Bill Burke Master

                  Please tell me how this Jenks MDP stuff is any better than MDBs.

                  Also, we have a different concept of Message Driven Pojos in that you can declare a business interface for your MDB and avoid JMS apis all together. Look at the @Consumer/@Producer stuff we have in EJB3 container.

                  • 6. Re: JCA antipattern? Or not?
                    Tim Fox Master

                     

                    "bill.burke@jboss.com" wrote:
                    Please tell me how this Jenks MDP stuff is any better than MDBs.


                    I didn't say it was any better than MDBs.

                    We have a customer who doesn't want to use MDBs but they want to be able receive messages in a managed environment transactionally.

                    Actually they are using Spring, and the Spring JMS template accomplishes this by creating a new consumer under the covers for every receive (!!) so I suggested they should try something different, since creating a consumer every time is going to make it crawl.

                    Also the JBoss JCA layer only provides message inflow for JMS AFAIK so this wan't an option for them either.


                    Also, we have a different concept of Message Driven Pojos in that you can declare a business interface for your MDB and avoid JMS apis all together. Look at the @Consumer/@Producer stuff we have in EJB3 container.


                    That's interesting - I will suggest this to the customer. Maybe this gives them what they want.

                    • 7. Re: JCA antipattern? Or not?
                      Bill Burke Master

                      Yeah, you're right, I'm wrong. You should write a simple MDB implementation that is non EJB. You could probably implement the Message Driven POJos we have in EJB3 land pretty easily too.

                      • 8. Re: JCA antipattern? Or not?
                        Weston M. Price Master

                         


                        Also the JBoss JCA layer only provides message inflow for JMS AFAIK so this wan't an option for them either.


                        This is not correct. JCA allows for generic inflow and is not limited to JMS based messaging. We have a few examples of generic inflow, most notably our Mail and Quartz RARs that provide this capability.

                        If the client truly does not want to use MDB's then *any* solution for them will be non-standard whether they are using Spring or not. EE environments rely on the MDB (not necessarily JMS) mechanism to implement inflow and message driven listeners.

                        Having said that, the only real 'hardwire' that forces the use of an MDB (which I just don't see as being that big of a deal, especially with EJB3), is the deployment. Currently there is no way to deploy a POJO listener and hook it up to a RAR.

                        Having said this, they would still need to write a custom RA to handle the inflow and delivery for their specific messaging type.

                        • 9. Re: JCA antipattern? Or not?
                          Weston M. Price Master

                          Also, if Spring does provide an ASF Consumer type template this would effectively get them what they want. There is nothing magical about what the JCA/JMS adapter does, it's simply a JCA wrapper around the ASF implementation of old.

                          • 10. Re: JCA antipattern? Or not?
                            Bill Burke Master

                            JCA may not know anything about MDBs, but isn't MDB the only *standard* way of using inflow? I thought there was no standard way of registering an activation spec and MEF, etc....

                            • 11. Re: JCA antipattern? Or not?
                              Weston M. Price Master

                              From my previous post


                              If the client truly does not want to use MDB's then *any* solution for them will be non-standard whether they are using Spring or not. EE environments rely on the MDB (not necessarily JMS) mechanism to implement inflow and message driven listeners.




                              • 12. Re: JCA antipattern? Or not?
                                Adrian Brock Master

                                 

                                "bill.burke@jboss.com" wrote:
                                JCA may not know anything about MDBs, but isn't MDB the only *standard* way of using inflow? I thought there was no standard way of registering an activation spec and MEF, etc....


                                There is nothing to stop somebody writing their own MEF (POJO based)
                                and activating their own endpoint if they can get a link to the ResourceAdapter.

                                1) There is an example of this in the new jca prototype
                                where the MEF is actually implemented via AOP interceptors.

                                2) This is one of the purposes of the RAR (MetaData) Repository

                                My preference is to have an abstract MEF implemented by JCA
                                that EJB2, EJB3, POJO can extend to provide the three pieces of metadata
                                that change.

                                isMethodTransactional(Method);
                                getClassLoader();
                                The hypothetical and non-spec getTransactionTimeout(Method);

                                • 13. Re: JCA antipattern? Or not?
                                  Adrian Brock Master

                                   

                                  "timfox" wrote:

                                  For straight JMS the above would again be clearly an antipattern.

                                  But what about JCA? It's my understanding that JCA does not cache jms consumers so every call to createConsumer() in the above is going to result in a new consumer being created on the jms provider. I.e. a heavyweight operation.


                                  There would be nothing to stop the JMS rar caching the consumers
                                  (like JDBC adapters can cache prepared statements).

                                  But I doubt it would work in practice.

                                  e.g. if the consumer is configured for read ahead
                                  there would be messages sitting in limbo until somebody reuses the JCA connection
                                  and "recreates" the same consumer.

                                  • 14. Re: JCA antipattern? Or not?
                                    Bill Burke Master

                                     

                                    "adrian@jboss.org" wrote:
                                    "bill.burke@jboss.com" wrote:
                                    JCA may not know anything about MDBs, but isn't MDB the only *standard* way of using inflow? I thought there was no standard way of registering an activation spec and MEF, etc....


                                    There is nothing to stop somebody writing their own MEF (POJO based)
                                    and activating their own endpoint if they can get a link to the ResourceAdapter.

                                    1) There is an example of this in the new jca prototype
                                    where the MEF is actually implemented via AOP interceptors.

                                    2) This is one of the purposes of the RAR (MetaData) Repository

                                    My preference is to have an abstract MEF implemented by JCA
                                    that EJB2, EJB3, POJO can extend to provide the three pieces of metadata
                                    that change.

                                    isMethodTransactional(Method);
                                    getClassLoader();
                                    The hypothetical and non-spec getTransactionTimeout(Method);


                                    Yes, this possible in *our* JCA implementation, but the only portable way of leveraging inflow is through MDB. Which was my point.

                                    1 2 Previous Next