Jacques Le Roux wrote:
Hi Deyan,
Thanks for your clear explanation and suggestion. As I'm busy with another
stuff, I have quickly put your comment as a quote in OFBIZ-3333 .
There is however a major issue that CAN NOT be fixed in the current
implementation: the list and sequence of entities to be synchronized gets
created by entities' timestamp - date_created_tx and last_update_tx. It works
as long as the clocks of all the syncing parties are in sync. You can easily
achieve this by using NTP for example - reliable enough. But if the clock of
one of the parties gets un-synced for just few minutes, and during those few
minutes records get inserted or updated than you are in trouble. Syncing the
clock back won't help you because you won't be able to sync the broken records
due to foreign key constraint issues. Examples I could give but I guess you
could think of such by yourselves :)
So IMHO the best approach for synchronization is not the timestamp but the TRANSACTION LOG. This approach is used in all major databases - m$ $ql, oracle.
The problem with that approach is that it is database-specific. As an
alternative, you could query the other servers for their current time
and generate a set of offsets to adjust the timing.
-Adrian
