Here is an example: On server A ( the one that pushes data ) we insert the following records with the following sequence and timestamps:
PARTY : party_id: 1000 , created_timestamp_tx : 6-APR -2010 20:00:00.010 PARTY_GROUP : party_group_id : 1000 ( FK to PARTY.party_id ) , created_timestamp_tx: 6-APR-2010 20:00:00:013 - three milliseconds later. That would the the database contents without issues. Now imagine we do a NTP time synchronization between the two inserts. The NTP sync "corrects" the system clock 5 ms back. The database contents now would be: PARTY : party_id: 1000 , created_timestamp_tx : 6-APR -2010 20:00:00.010 PARTY_GROUP : party_group_id : 1000 ( FK to PARTY.party_id ) , created_timestamp_tx: 6-APR-2010 20:00:00:008 - earlier than the PARTY record. When the server queries the records to be sent for synchronization the result will be: PARTY_GROUP : party_group_id : 1000 ( FK to PARTY.party_id ) , created_timestamp_tx: 6-APR-2010 20:00:00:008 PARTY : party_id: 1000 , created_timestamp_tx : 6-APR -2010 20:00:00.010 The server that accepts the push sync will try to insert first the PARTY_GROUP record and will get a FK constraint error - the PARTY record is missing. And that is just an easy example - with parties and party groups. The examples with invoices, orders, items and last but not least: acctg_trans and acctg_trans_entry records are much more complex to recover from. So that is my concern actually. I experienced it, also it's pretty easy to verify :) -- deyan -----Original Message----- From: Adrian Crum <adri...@hlmksw.com> Reply-to: user@ofbiz.apache.org To: user@ofbiz.apache.org Subject: Re: JUNK->Re: ofbiz entity sync. Date: Tue, 06 Apr 2010 10:48:28 -0700 Deyan Tsvetanov wrote: > Hi Adrian, > > yes , my current approach is database specific. It was implemented under > pressure when I found out that ofbiz sync does not work, at least in my > setup :) > > So my suggestion and idea is to implement database independent solution, > I would do it but may be in few months. > The approach suggests that we implement a triggering function in entity > engine which would allow us to do event based handling on insert / > update / delete events. So in general we say: onInsert for a specific > entity execute some java method. > > Entity Engine would either do that event handling completely in it's > java code or would generate and create real database triggers, if the db > engine supports it. I don't know if there is such a feature already, I > did a very quick search in the docs and found nothing. May be > Jacques could help here ? :) > > Jacques, off the topic - is there an option to call native stored > procedure in the database from entity engine ? It comes very handy > sometimes ;) > >> As an alternative, you could query the other servers for their > current time > > and generate a set of offsets to adjust the timing. > > > Deyan: Yes, but the clock of the main server also could run faster or > slower and in few weeks or months would eventually get synced by NTP. > That would also cause issues. Another problem is that you insert > entities with local timestamp and synchronize them using a remote one > for comparison. So you need to calculate time diff, too much logic i > think :) I might be wrong, but the only issue I see with servers time drifting is when to trigger an update. I'm not an expert on entity sync, but from what I understand, timestamps are compared to see if server B's data changed since the last sync. So, you query server B for its current time, calculate an offset from your time, and adjust the query's timestamp. -Adrian
