The condition that should keep the message within the queue would be some kind of error code. If it occurs then keep the message there and retry until it no longer occurs. That would really be the external process for the MDB to decide whether to consume the message or not. For now I'm presuming there are no infrastructure problems and just concentrating on the business processes. With respect to the retrial mechanism of JMS that sends failed messages to the DMD - I presume these are failed messages because of infrastructure problems?
If the use of transactions can dictate which messages can and can't be consumed then that certainly does sound interesting. Upon the error code being raised by my business process there will be a transaction rollback and I believe the message will remain within the queue. But the key issue here is when will be the next time that the MDB will try to consume the message again and do I have any say on this via Glassfish configuration or JMS API?
If neither provides such a facility then I may need to write a simple scheduled job (e.g. via Quartz) which would actually do the polling on an hourly basis but is this a good practice? I know that my problem sounds trivial but I would very much like to use Glassfish's power that's at my disposal to get the maximum benefit out of it.
Thanks to everyone in advance for any pointers they can give me.
John
[Message sent by forum member 'johnstv' (johnstevens3_at_hotmail.com)]
http://forums.java.net/jive/thread.jspa?messageID=366723