This doesn't look right, For such traffic and data threshold, usually a dispatcher is used. you might need to (as this might be a server balancer) follow a pattern similar to business delegate which reads the message off the queue  and communicate with stateless session beans for further processing.

Now, depending on where the queue is deployed (presentation / web / client / server tiers) you can follow different patterns like business deligate, service to worker, etc

Consider the fact that if the number of queues grows to response to a higher data threshold, you might need to create instances of the dispatcher (MDBs) and balance the load among them.

You might need to perform a performance investigation to choose  the best architecture.

i'm not clear


so can a single MDB read  from 40 queues?
was this the original question

Yes, the main idea is to keep a single MDB and let it read  from the 40
Queues.

It's now just the matter of 40 queues, you need to measure the data / message traffic targeted to those queue.

A few questions for you which may help you consider some architecture practices.

1. Can a single MDB handle  your message transmission to the 40 queue?

2. Have you considered scalability? what if your system grows and you get more message threshold to the 40 queue? Can your existing architecture response to those with acceptable performance?
again, I guess why not consider a balancer which forces one or more MDBs to process the messages  depending on the message rate? otherwise if this keeps growing, your users/customers will experience the message "Server Busy, Please try again later"

wat is the limit of an MDB?
can it read  simultaneously from infinitelty no: of Q;s
wat is the upper limit , when would u have multiple
MDB's

is it like servlet service() method which can read in
a multithreaded way as many inifinety no: of Q

I could find these for the moment,

docs.sun.com/source/817-0354-10/overview.html

docs.sun.com/source/817-0354-10/imq_sys.html#13500

If you're interested, I try to find the Weblogic article on MDB and management of queue. If I find them I try to send them on

you need to be careful when you are talking about queue  / topic, I believe topic means pub/sub and queue if for point-to-point. although I guess you mean pub/sub here, am I correct?

2.1 spec does not clearly talk about number of subscriptions, so I believe this could be JMS implementation specific. I know that WebLogic has restrictions on number but in return it introduces a set of alternatives. (see Web Login for more details, I have a link when if I find it , I will send it on)

Re the second question, it doesn't work like servlets. Calls to OnMessage are serialized by the container so no code is necessary to make  the method reenterant. asynch processing of the messages  of the queue are done through the management of pools of MDB.

I guess you need to revisit your archietcture a bit. again I think having a load balancer could distribute the coming messages and dispatch them among your application  consumers, (MDBs). On the other hand if you also consider the container management of MDBs pooling in each cluster, you will get high availability, load balancing and scalability with this archietcture.

Let me look into my favorites to find the link to WebLogin article and I will forward it then.