You could write an MDB with receives message and stores them in database. Then a timer fires periodically, aggregates the message and send a second "aggregated" message to a second MDB. The second MDB would be the one doing the real processing. Depending on how you handle the transaction, the whole batch would either succeed or fails.
A variant would be to rely on JMS itself to queue the message, then the timer open a connection, consumes the message from queue1 and send them one by one to queue 2 which are then process with a MDB. The system must be sized and configured so that no message get discarded from queue 1 in case the load is too important.
You could also process the message in the timer itself, as suggested in previous posts. The different will be mainly in the nature of the retry mechanism. MDB can be configured with retry attempt, dead message queue, etc. Timer also have retry mechanism, but are a bit more limited.
[Message sent by forum member 'ewernli' (erwa...@gmail.com)]