JCA antipattern? Or not?

[timfox]

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?

[weston.price]

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

[timfox]

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

[weston.price]

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.

[timfox]

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?

[bill.burke]

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.

[timfox]

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.

[bill.burke]

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.

[weston.price]

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.

[weston.price]

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.

[bill.burke]

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

[weston.price]

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.

[adrian.brock]

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

[adrian.brock]

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

[bill.burke]

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.