Supported replication protocol(s) [CORE6537]

[firebird-automations]

Submitted by: @aafemt

It would be good to have a way to find out which protocols (block formats) are supported by IReplicator interface.

[firebird-automations]

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

[dyemanov]

I'm wondering whether it makes sense to add a multi-purpose getInfo() method similar to what we have in other interfaces. This would be consistent, even if looking too much "legacy".

[aafemt]

Taking into account that IReplicator is received from IAttachment and has no additional properties (in contrast to ITransaction for example), personal getInfo() in it may be an overkill. A new item for IAttachment::getInfo() could be enough.

[dyemanov]

Don't you think there could be other replication related info items in the future? Statistics (number of replicated blocks / transactions / records), for example?

[AlexPeshkoff]

I suggest to take a look at all this from one more point - can attachment have >1 replicator? If not in v.4 - take into an account what can be later, in theory, etc. If yes - having getInfo() in IReplicator is close to unavoidable, cause different replicators may have different properties.

[dyemanov]

I expect to have multiple replicators per attachment in the future.

[AlexPeshkoff]

In that case using getInfo() in attachment to obtain information about replicators would be very bad API - each time one will have to provide info about what replicator that info will be. Even list of protocols can be different - for example due to configuration issues.

[aafemt]

Don't you think there could be other replication related info items in the future? Statistics (number of replicated blocks / transactions / records), for example?

So far I see no use for such items. All stats can be counted during block building and the block is either applied as whole or rejected.

different replicators may have different properties.

There is no way to set them. createReplicator() has nothing like Replication Parameters Block among parameters and the same configuration is unavoidable applied to all IReplicator instances created from the same IAttachment.

[dyemanov]

Now I start to question the idea about multiple replicators myself. The original goals I had in mind are:

1. parallel load of the single data stream
2. replication from multiple sources

(1) is not going to work in a single attachment due to its serialization. (2) may load multiple streams independently, but again not in the really parallel mode. This makes the whole idea rather useless, I'm afraid. Can we think of any other possible use for multiple replicators per attachment?

[aafemt]

Why I like to have them is errors' handling. If separate instances of Replicator is used for each transaction and something bad happen you can just kill one instance and don't care about interference with others.

For single instance model the whole separate interface is meaningless and "process" method may become a method on Attachment or (even better) Transaction.