# Uni-directional synchronization and locking issues

Suppose there are two databases, $D_1$ and $D_2$. Let's further assume $D_1$ is always up and $D_2$ can be down sometimes. When it goes up again, it has to restart.

$D_1$ is filled by say a dozen other systems with event messages. Those messages have IDs and might be updated or deleted. $D_2$ needs to be in sync with $D_1$, which is realized by:

• on restart, pull all data from $D_1$. During this pull $D_1$ is locked, thus all senders to $D_1$ need to wait.
• otherwise $D_1$ always informs $D_2$ of updates by sending all updates. (During fetching, the data is locked of course.)

Now the question: what kind of blocking behaviour can we expect from $D_1$ and $D_2$?

In particular I find the following corner case interesting and instructive:

$D_1$ currently has a long list of events and the sender systems send a lot of new events/updates. $D_2$ just went down, goes up now and needs to fetch events from $D_1$, thus blocking the whole chain.

• Is this a real database system? (usually unidirectional DB sync works in a different manner) – Vor May 7 '12 at 14:57
• It's a custom system that is in the process of being build. Not sure what you mean by "real", but it will not be Oracle, Postgres or the like... Anyways, do you have any references about unidirectional DB sync? Or can I ask you to describe it in a few sentences to me please? – user694971 May 8 '12 at 8:51
• @Kaveh: My question is still meant as above. I am interested in the theoretical/mathematical constraints of the described model, not about the best approach regarding DB sync. – user694971 May 10 '12 at 9:55