Hi Deyan n others I have also worked & solved many sync problems in ofbiz in my application:
1) As you said while sync is in progress if server crashes, the status in EntitySync table gets in running state and we can't sync further until we manually change it even if we restart server it remains in running state To solve this problem: I created a new entity SyncStatus on client side to maintain the status of sync, in that ist status is Not Started, when service runEntitySync or runPullEntitySync starts I set the status of field as running and when service returns (whether fail or successful) I updated status to finish. I also added code, that if server restarts and if this field status is running change it to not started, By this I solved the above problem: *) If client crashes, then after restart, status in SyncStatus table will be Not Started. *) If server crashes, then service will be failed and status will be finished and no further problem. 2) There were other problems like if sync(push or pull) is running, and one other job of same service is also created then we get exception "An instance is already running" By using above status in SyncStatus table when A job of sync is running, I just cancelled out all other jobs of same type. 3) I also solved "Connection refused" problem by same method even I displayed message on screen rather than giving exception on console. 4) I did not get your point of updating time stamp, I did not get this problem because In push or pull sync the successful timestamp is updated on EntitySync table on client or MCS side only if sync is successful, if server crashes or sync fails this field is not updated, but yes there are some issues: *) If we have 2 hours of sync, n sync fails on last minute. then in next sync as sync successful status has not been revisesd, next sync will pick the status of previous one, as a solution I think we need to keep updating syn status in EntitySync table after particular intervals. but how to decide these intervals b'coz tables are linked with foreign key constriants. *) One problem with connection refused in push and pull case is that, In pull sync first connection is established then data is prepared for sync while in push sync first data is prepared and then conncetion is established. So in pull sync we get connection refused problem in earlier stage than push sync. We can say in push sync if there is no MCS (Or MCS IP address is wrong), Our code is doing efforts in preparing data that effort is of no use. 5) If we place order on POS side and try to perform push sync, some time I was getting random exceptions due to order header or Order Status table, I solved the problem. Explain: In placing order (or others) if you have used a database trigger (eecas) like if an entry is created on A table create an entry on B table. Now wile sync if MCS is also having same trigger then as a entry is created (by sync) on A table , trigger is fired and an entry for B is created. Now for one A, B will be having two entries that creates random exception So I want to ask, that mean for sync there should not be ant trigger on opposite side(means for push MCS and for pull POS), how we will maintain that ??? I did not get your concept of using XML file inspite of RMI. Could you please give some details regarding that???? Even I agree with the fact that RMI takes long time. Regards: Pankaj Jain ______________________________________________________________________
