db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre Tjeldvoll <Dyre.Tjeldv...@oracle.com>
Subject Re: Derby replication system - Need help
Date Tue, 18 Mar 2014 10:43:29 GMT
On 03/17/2014 08:48 PM, spykee wrote:
> 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.

I agree, starting 20K threads/sec does not sound like I good idea. But 
since I'm not familiar with these other technologies that you use, I 
don't understand why you need to fire a thread per message. Why can't 
you have a dedicated sender thread that reads everything in your 
queue-table and sends it (through whatever api you have to the MQ 
system). You could either have the sender thread check the queue table 
periodically, or have it sleep on a monitor which the trigger action 
grabs when adding new records to the queue table.

> 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.

Why can't everything from the Derby trigger to the message queue be 
inside the same jvm?

> 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.



View raw message