Home/ Questions/Q 6868455
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T03:26:11+00:00

I have a java concurrency problem, it goes like this: There is a Servlet

  • 0

I have a java concurrency problem, it goes like this: There is a Servlet (serv1) that stores objects (representing messages) into a database. There is also a Thread (t1) that looks (in the database) for unsent messages and delivers them. t1 runs every 5 minutes so, for efficiency purposes, serv1 notifies t1 every time it stores a message.

The question is: How the notification process is going to behave on a highly concurred scenario where serv1 is receiving an extremely high amount of requests and thus t1 is being notified so much that it’d simulate a “while (true)“?.

Another question: How does the notification process will behave if serv1 wants to notify t1 but t1 is already awake/running?

Thanks in advance!!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I don’t think this is an issue @Wilmer. I suspect that the notification itself is relatively cheap compared to the cost of consuming and processing your messages. If you are spinning consuming then messages then removing the notifications is not going to help the process and you will have to block your serv1 thread somehow or offload the jobs to run later.

    In terms of notifications, if no one is waiting then the notify() is effectively a no-op. This is why it is important to check to see if there is anything to process before waiting on the signal — all in a synchronized block. It is best practice to also loop around the wait and check again when we are notified. See this race condition.

    In general, this is a very common practice that is used in virtually all producer/consumer thread models that I have seen. The alternative is not to handle the square wave traffic changes. Either your consumer (t1) is waiting too long and the buffers fill up or it is spinning too much and is consumer too much CPU checking the database.

    Another thing to consider is to not use the database but to put the objects into a BlockingQueue for t1 to consume directly. If you need to store them in the database then put the IDs of the objects in the queue for t1 to consume. The thread will still need to poll the database on startup but you will save the polls later in the process.

    • 0