Hi Dyre , Thank you for your comments.
The JMS Queue ( Topic ) has an API, and it will be called from the stored procedure. The scope of the queue is to be an entry point of the messages publishes by the stored procedures, messages which will go to a cache(s). The architecture is simple: --- db_tables--->triggers for INSERT/UPDATE/DELETE----> put data to the audit tables, populate tReplicationMessage table--->trigger the INSERT into tReplicationMessage ( one thread/message )--->CALL the stored procedure, send the message in the queue----> publish the messages to all readers ( cache(s))!. Now, I want to avoid creating one thread/message when sending it from the db ->queue. AND beside this, I thought that there may be other solutions than the one I mentioned ( tReplicationMessage ). Firing one thread per message is bad in my opinion, and this should load the db + network. For queue I use OpenMQ, and by itself will publish the messages received to all subscribers ( no need to do anything here). My problem is not the queue, and it is the "way of how the messages arrive from db tables to the queue". From the queue to the cache is purely Java + message format, which is google protocol buffers. Any other tips other than using a single table which will fire one thread/message (the stored procedure triggered by the INSERT trigger from tReplication table) ? Regards, George -- View this message in context: http://apache-database.10148.n7.nabble.com/Re-Derby-replication-system-Need-help-tp138003p138039.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
