Hi Dyre and Rick,
My original design includes the following flow of data :
--> application tables (e.g. tBook, tBookCharacter ...) - >trigger - >
tReplicationMessage ( this is the queue mentioned by you in order to avoid
the transaction issues!!! ) - > trigger + a stored procedures - > JMS Queue
- > other applications ( Cache, web services....etc).
E.g.
-- application table
create tBookCharacter(
bk_character_id INT not null GENERATED ALWAYS AS IDENTITY (START WITH 1,
INCREMENT BY 1),
bk_character_name VARCHAR(80) not null,
);
| triggers
\ /
--- the Queue
create table tReplicationMessage(
msg_id INT not null GENERATED ALWAYS AS IDENTITY (START WITH 1,
INCREMENT
BY 1),
msg_table_name VARCHAR(25) not null,
msg_table_code VARCHAR(25) not null,
msg_operation CHAR(1) not null,
msg_delta_columns VARCHAR(255) not null,
msg_pk_column VARCHAR(25) not null,
msg_pk_value VARCHAR(31) not null,
CONSTRAINT msg_operation_c1 CHECK (msg_operation IN ('I','U','D'))
);
| <triggers + stored procedures > - push a
specific message( format in google protocol buffer)
\ /
JMS Queue
|
\ /
Other messages consumers ( e.g. web services)
My tReplicationMessage table will suffer some schema changes.
*Thank you very much for the advice, really helpful.*
Cheers,
George
--
View this message in context:
http://apache-database.10148.n7.nabble.com/Re-Derby-replication-system-Need-help-tp138003p138235.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
