Hi all, Just adding more info, in case someone else will desire to implement same stuff : * implementing this architecture ( using the mentioned approach, tReplicationMessage) + triggers + stored procedures ( this should be add only if higher functional requirements are needed, complex application business logic ) works very well. * the polling can be done using Apache Camel SQL/JPA ( I preferred SQL, is lighter ): ** you can achieve a timer approach using the SQL endpoint from Apache Camel - Poll periodically ** in the SQL route you can add parallel processing by adding an Executor of Thread Pool/Fork Join Pool - works pretty well, scalability . ** using this approach you can process a lot of messages/second ** easy to achieve transactionality ** easy, fast and efficient to integrate this with external systems *** Personally I used websocket protocol to transport the messages to other external applications/systems + with a good serialization ( e.g. Kryo ) to lower the bandwidth consumption.
Cheers, George -- View this message in context: http://apache-database.10148.n7.nabble.com/Re-Derby-replication-system-Need-help-tp138003p143749.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
