I have a question about the performance of the DBReplicator on an environment with 140 subscriber servers.
I've read a topic saying that the DBReplicator handles the subscribers connections one at a time, causing problems with a large number of subscribers trying to connect to syncronize at the same time.
This is true? I'm analyzing the possibility to use DBReplicator on a system with 140 branches that have to synchronize some tables with a master database.
Someone knows if this is possible or if I will have problems doing this?
Thanks in advance,
Alexandre.
Sorry for the delayed
Sorry for the delayed answer, but yes, you are correct. Currently, dbreplicator handles subscribers connections one at a time, so that only one sync session can happen concurrently. You can have as many subscribers as you'd like, but only one can be syncing at any given moment. It is rather fast, though, so it may still work for you.
The problem comes not in threading java, which is very good at that sort of thing, but in maintaining data integrity. To do this properly, the publisher database needs to support the SERIALIZABLE transaction isolation level, and implementing this can negatively impact database performance. Because it is trigger based, it is not replicating TRANSACTIONS but individual record changes per table. This means that if you're not serialized, you could end up with data at least temporarily in an improper state.
It definitely bears looking into, but it really becomes quite complex at that point.
B