I am creating an application which uses a database as a persistent queue. I have one process writing to the queue (which happens to originate from a servlet), and one process reading from the queue. This seems to be the classic producer-consumer problem, except that I cannot use notify/wait because I am using different processes in different JVMs (at least that is my understanding - I am under the impression that a servlet executed by Jakarta-Tomcat and a processes executed via the command line run in different JVMs).
I know I can use RMI, CORBA, or Sockets to communicate, but I dont want the queue-reader to be doing any sort of polling, I want it to block until something is added to the db (without constantly reading the db). I cant think of a really clean way to implement this, is there any 'natural' way to this in Java?
You named a few inter-process protocols. I'd go with one of those that makes you comfortable. Probably sockets for me. The process that writes the database can publish "I just updated the database" to all interested listeners. I'd make interested listeners do some kind of subscribe or addListener so the db updater doesn't have to know about them at compile time. JMS has a good pub-sub paradigm if you happen to have a JMS provider under the covers somewhere.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Peter den Haan
Joined: Apr 20, 2000
An RMI-callable object or a daemon thread waiting for socket data would do the job (both are one and the same thing anyway). But why on earth don't you use JMS? It sounds like it's exactly the abstraction you need.