Yea, the problem is two fold.
The "nice thing" about MDBs is that they are simply "automatic", you don't have to write any of the listener code necessary to mange the connection. In most use cases, that's a feature. Obviously in your case, it's not.
If you disable the queue itself, then your clients have nothing to connect to, which isn't what you want either.
You may want to try something potentially hacky.
Basically, I would modify the MDBs to look for some property (probably in the database) that can be changed on the fly.
When the property tells the MDB to "shut down", the MDB does a couple of things.
One, it starts rejecting messages. It simply doesn't accept them, rolling back the transcation.
And, two, it start sleeping a LONG time (like, say, 1 minute) for each message it recieves. This way it's not rejecting vast amounts of messages, but only 60/hour (multiplied by however many MDB instances you have).
You will have the issue of configuring your system to handle the rejections artfully (so that it doesn't dump them in to a dead letter queue, say).
But, it will effectively "kill" the MDB. I assume you simply want to delay processing, that's why you're disabling the MDB. When you want to reenable the MDB, reset your flag, and messages should start to flow again once your 1 minute timers start expiring.
It's not a particularly formal mechanism, nor elegant, but it should work.
It may also work where the MDBs don't reject messages at all, but simply never finish. They simply continually poll your global flag (again within a long sleep loop), and the JMS queue just sits there. You may get timeouts on this tho, I've never done it.
But I'd try both techniques to see which fits your needs better and smells better. :-)
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=279491