Very Urgent: Performance => local stateless ejb vs objectPool

[shivnarayan]

Hello Guys,

Please suggest me which approach would provide me more performance.

We are developing an High performance Message Processing Engine, which needs to process very high volume of messages and needs to be reliable,HA,high performant,transactional aware etc and needs to use the resources very carefully.

We also needs application to scale well with high volume data capability.

Hence for scalabilty and high performance I am considering using either Local SLSB ejb or ObjectPool.

EJB. =>

If I will local SLSB EJB, It would provide scalability with transactional capability. My app server (weblogic 9.2) will handle object life cycle,pool, multithreading etc.

ObjectPool: =>

If I will use ObjectPool, I would be able to make it transactional aware using TransctionInterceptor (Spring AOP). Looks like it will be more simple and performant.

Please suggest Is it right idea to call ObjectPool from MDBs.


Please suggest which one I should choose.

[wpoitras]

I would suggest neither. You don't need to pool objects unless there is a compelling reason to do so. You can attach a stateless POJO to a queue using the asynchronous JMS stuff in Spring 2.0. Adding pooling or session beans adds overhead you may not want.

In thinking about it briefly, you might consider writing your code such that you can decide after some testing. Just make sure your message processing logic is in a POJO that you can attach to the infrastructure that makes the most sense for your system. Spring helps you do that allowing you to add failover, transactions and other services without having to add such logic to your POJO.

[debasishg]

I completely agree with Bill. Modern day JVMs are highly tuned for fast allocation, generational garbage collection and Escape Analysis (offered in Mustang) techniques. I would think twice before going for object pooling. Even if, I decide on pooling, it should be a reactive process, only when I am convinced that it will definitely lead to an improvement in performance in my specific application. But, I think gone are the days when we can accept object pooling in Java as a definitive optimization step. See here for more details ..

Cheers.
- Debasish

[karldmoore]

There has been a recent flurry of articles busting old truths about performance (likewise urban legends). All very interesting. I'm usually quite cynical about performance issues until I can actually prove there is a problem. I've actually seen people spend days "improving" performance only to see the opposite. I guess you just have to profile it as you go and improve if necessary in a measured way.

[shivnarayan]

I would suggest neither. You don't need to pool objects unless there is a compelling reason to do so. You can attach a stateless POJO to a queue using the asynchronous JMS stuff in Spring 2.0. Adding pooling or session beans adds overhead you may not want.

In thinking about it briefly, you might consider writing your code such that you can decide after some testing. Just make sure your message processing logic is in a POJO that you can attach to the infrastructure that makes the most sense for your system. Spring helps you do that allowing you to add failover, transactions and other services without having to add such logic to your POJO.

Bill, Thanks for your time and reply.

What I understand from you, Is that rather than using MDBs I should use Asynchronous Message POJOs.

Could please help me in understanding if MDBs have more running overhead than POJOs. One best part in POJOs is that We can use all spring features (Transaction, Interception) in plateform independent way.

1. Approach :

MDBs -> stateless session EJB(MessageHandler) -> MessageRouter

2. Approach

MBBs -> Plain Java controller bean (MessageHandler) -> MessageRouter

3. Approach
Asynchronous Message POJOs -> MessageHandler -> MessageRouter

Can we discuss which approach will be better and why?.

Another thing which we need is XA enabled transaction, Because we need transaction boundary across JMS, database, and publishing message to destinations queues.

Could you suggest any workaround for XA, because I think it would be overkill.

Can you also suggest if I can implement transaction batching with Asynchronous Message POJOs, something like where I can embed batch of messages as part of one transaction, instead processing each message independently. This is feature is provided by weblogic 9.2.

[wpoitras]

I haven't gotten a really good answer for why MDPs are better than MDBs other than they can run outside of EJB container.

I don't think MDPs work with special cases like distributed destinations. Minimally I have more confidence that MDBs work better with a container's native extensions than MDPs will.

Personally I use MDBs which is a just a shell which delegates to a stateless POJO.

Approach 2 and 3 are better than 1 because stateless session beans are allocated in a pool and are executed often in their own threadpool (that really is a function of the app server, I've read that WebSphere will execute a local stateless session bean in the same thread as its caller if it can get away with it). But as I mentioned MDBs vs. MDPs there isn't that big a difference.

If you need to put the database and publish to a destination queue in the same transaction, I don't think there is a way around XA transactions. But that shouldn't be a big deal with Spring based applications. Spring can participate in an XA transaction as easily as a non-XA one through the PlatformTransactionManager interface and transaction proxies.

[wpoitras]

There is a new feature in Weblogic 9.2 called "Logging Last Resource" which allows your JDBC transaction to be handled like a local JDBC transaction inside of the XA transaction which gives better performance. Spring shouldn't know the difference because its using JTA to manage the transaction.

I also don't see a problem with batching messages. Spring will join whatever transaction is present. If that transaction spans multiple invocations of the MDB it shouldn't matter. Its advanced functionality like this which probably makes MDBs superior to MDPs.

[shivnarayan]

Thanks Bill for your valuable input.

I would like to throw this question to all readers in forum, why should we prefer stateless POJOs ahead of stateless session bean.

Because All app server containers provide rock solid life-cycle management, transaction support, thread safe etc for stateless session bean. moreover they are scalable as all java books says this.

Then what should be compelling reason to prefer stateless POJOs over EJB. Specially if you are using spring framework.

Thanks in advance for your time.

Shiv

[manifoldronin]

Hi Shiv,
You might find Rod Johnson's "J2EE Without EJB" interesting. Especially Chapter 5 "EJB, Five Years On".

[Niels Ull Harremoës]

One reason for POJO's would be simplicity (fewer/simpler deployment descriptors) and ease of testing.

One reason to use MDB's would be container support for configuration and management. They can be configured through deployment plans.
An administrator can configure max number of instances, specific thread pools to use etc etc. They can be shut down or started up as he deems necessary.