CODEWITHSUNDEEP
javamultithreadingweb-servicesjax-ws
Robin Bajaj
Robin Bajaj

Reputation: 2072

inter-thread communication between java application and jax-ws web service

my jax-ws web service (after it gets hit by the client request), sends a request to backend legacy platform (through a socket) and then waits for 20 seconds for the response.

Before it makes that request it updates a table with its unique transaction number.

A separate listener thread (standalone java application) is waiting on that socket for the responses, each response will have the transaction number in it to identify which request (previously sent) its associated with.

how can this standalone java application communicate to the thread waiting in the web service that its response has come and it can continue its processing.

Currently i am thinking the listener thread can update the table (based on the transaction number) to indicate the response has arrived. And the web service thread can keep polling (check every 2 seconds) in the database whether the response has arrived or not.

I am looking for some push notification in this case instead of polling. How can my web service thread be notified when its response has arrived.

Upvotes: 1

Views: 1129

Answers (1)

davidfrancis
davidfrancis

Reputation: 3849

Assuming the thread to service the request and make the socket request, and the thread receiving the socket response, are all in the same jvm:
You can use the standard Java wait/notify pattern.
http://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html.

Basically your req/socket thread will create an object (a 'lock' object) in a singleton (or similar) map, the key being your unique transaction number. That thread will then wait on that object. This blocks that thread until another thread does a notify on that transaction id's lock object.
Note the lock object can be just an Object.
You can also put a timeout on the wait to avoid waiting forever.

Your other thread will then grab the lock object for the transaction id and do a notify on it. This then unblocks the first thread.
If the second thread finds no lock object for its transaction id then something has gone wrong and you'll have to log an error or similar.

Ps as the map is a shared resource you will probably need ConcurrentHashMap. Otherwise you'll probably hit issues with multiple threads updating it concurrently.

Upvotes: 1

Related Questions