db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From spykee <toma.georg...@yahoo.com>
Subject Re: Derby replication system - Need help
Date Mon, 17 Mar 2014 19:48:06 GMT
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 (

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) ?


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.

View raw message