Really, you should just have processes populate a table, then have a regularly scheduled process scan and reap that table, deleting successful operations, and leaving those with errors.
This gives you the semantics you are looking for, and it's simple to implement. You can use a TimerBean to pull it off.
JMS queues really aren't designed for lingering messages, or message management.
The message queues tend to be opaque to the consumers, they don't know how many messages are left, what kind of message are left, etc.
If you want to stay with the JMS as your implementation hammer, I'd have a TimerBean wake up, connect to the JMS server, read and process all of the messages on the queue, and toss all of the bad messages on to an internal list. When you reach the end of the queue, you close the connection, and then you can post the messages back on to the same queue for next time.
But, from a management perspective, that doesn't really give you a lot of insight in to what's going on. You can't query the queue to see what bad messages are left. You can log a status message "Processing finished, resubmitted XX messages", but then you're pretty much stuck waiting on those messages until the next interval.
If they're in a DB, you can at least say "you know, this message is horribly bad" and delete, or move it, or whatever.
Mind, this depends on your JMS provider, in terms of what introspection they offer on their queues in terms of management, but, in general, you don't get that kind of granular access to the queue elements.
The downside of using DB tables for queue, in general, is all of the polling and what not. But since you're running once an hour, that's simply not an issue here.
So, I'd just go with KISS and use a DB table.
[Message sent by forum member 'whartung' (redrocks_at_sbcglobal.net)]
http://forums.java.net/jive/thread.jspa?messageID=366912