> Thanks Felipe. I was wondering if my requirement is actually an orthodox way of doing things? I'm sure with other JMS providers you are able to have a queue polled periodically. Using a database table for this basically discards the need to have a JMS queue at all as I may as well put my messages into that table instead of the queue ;)
Yes, DB simulating Queues is an option, actually it is the
old-fashion-hacky way of doing that :)
> As messages come through to the queue there could be hundreds and what I don't want is for them to be read immediately.
I just can't understand why :) JMS Queues are designed to provide
extreme throughput and to be as fast as possible, you should be able
to delegate this decision to the container and benefit from the
container ability to optimize the memory and processing consume... If
it for performance or processor consume reasons, you should rely on
the container.. if it is a business constraint, then I don't know..
> Scanning through such a queue periodically would benefit me more.
it seems you are designing your software for batch processing instead
of streaming the producer-consumer relationship..
> Does anyone know if Glassfish is flexible enough to handle queue polling or is queue polling something which goes beyond the operations of a JMS provider?
I don't know.. I will be listening your thread to see if such thing exists :)