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' (redr...@sbcglobal.net)]

http://forums.java.net/jive/thread.jspa?messageID=366912