On 18/03/2014 22:58, spykee wrote:
Using the monitor approach I will have to make *2 steps:*
- throw a notifier message from the db to the monitor thread ( execute a
stored procedure)
- the monitor thread will then have a logic, and then query the table for
the changes and publish them to the queue
-> this approach will ALLOW me batching the messages ( this should improve
the performance)!!
With the first approach I have to make *1 step:*
- throw a message directly to the queue
-> this approach will NOT allow me batching the messages( this should
decrease the performance)
I do something similar (but <20K per sec; more like 100/sec on a bad day) by
using a trigger to insert a record in a separate table and then have a thread
which polls the table. Works quite well. Plan B would be to call a Java
procedure from the trigger which does an insert to a table or an in-memory queue
and then calls notifyAll() on the consumer thread. I prefer a table as I'm less
likely to lose stuff if the system crashes, and it's probably dealt with and
deleted before the disk catches up.
HTH,
--
John English
