I prefer a profile to keep the connectivity details; because periodic database  check/access brings excessive overhead into your system performance I would suggest the following which I think we can argue over it


If you can use a middleware component (lets call it an event handler) that reads the tunneled events  and populates them into database, and at the same time send a signal (internal event) to a coordinator which can distinguish between event types. This is a message consumer coordinator


Coordinator will then (based on the type  of event) can notify a corresponding message consumer of existence of a new event, and the MDB can then start  processing it. (Notification = pushing the event into the queue  of the MDB)

On startup  of the application, message consumer can query database for events that are already persisted and not processed (probably based on time) by interfacing with database by probably running a sql command or store procedure to read the event.

This means that message consumers are already running and subscribed, and if the traffic gets more loaded you can use some load balancers to balance the load over number of similar consumers. Of course you have MDB per event type (this is what I read from your requirements below). Because single MDB will be blocked until one of its own messages is processed, you can use some dynamic  behavior to avoid this. This would be also helpful; to avoid any failure in case an unknown event type has been received.

à Event handler à persist in DB + signaling Coordinator -> message consumer (no DB access) -> event processor

Start up:

Message consumer -> DB to collect events and process

This does not have frequent DB access which is a benefit

Your information  is helpful, and I was wondering if you know of any examples  of how I would build the subscribe part  of my application using JMS?

If it is a requirement that we repeatedly process events(not only at start  of application) we can create  a thread that runs at start of application and in a while loop processes events  and then goes to sleep for a while.
Hear is sodo codes:

public Class processor extends Thread{

   private sleepTime = 100000;

   while(true){

        process events(call a stored procedure....);

        sleep(sleepTime);

    }

}

Container somhow resolves the issue with loosing events/messages in case your application goes down. If you use durable subscription model, any message that has been sent during the down time of you application will be persisted until they are processed by the subscribers. So when you app comes up, you won't loose any messages. Having said that this brings a bit of overhead due to its persistancy. For more information  I recommend you to have a look at EJB spec.

Regarding the point Reza is making, it's good but not for J2EE as this is framework internal responsibility. Although I want to argue with the idea  somehow, because there are drawbacks to it. specially the concept of predefined sleep interval. I understand that you keep the interval in a property file  so it can be modified later according to the condition, but, if the network throughput is too high or too low, you can never know what interval to specify, so I rather keep the applicaton smart enough to adapt to the network load and to be flexible.

For instance  if object A is sending message to B (B is consumer)

I go with a psuedo code as follow:

A->queueTheMessage();
A->signalB();

B::queueConsumerThread()
{
 while(true) {
   waitForSignalFromA();
   while(there are messages in the queue){
       read_Off_The_Queue();
       process_Message();
   }
} // considering the proper lock and unlock stuff (out of scope)

while loop should be in run method of thread!