Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Message-ID: <274344190.4651270549653703.JavaMail.jira@brutus.apache.org>
Date: Tue, 6 Apr 2010 10:27:33 +0000 (UTC)
From: "Jacques Le Roux (JIRA)" <jira@apache.org>
To: dev@ofbiz.apache.org
Subject: [jira] Commented: (OFBIZ-3333) Issues with EntitySync
In-Reply-To: <2055424750.1260630558110.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OFBIZ-3333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853837#action_12853837 ] 

Jacques Le Roux commented on OFBIZ-3333:
----------------------------------------

Here is aquote from a Deyan's message he sent us personnally

{quote}
There are some major issues that CAN be fixed in the current implementation: error recovery - due to interrupted connection between the two servers, sync speed - RMI can be removed , etc. 

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. 

For a customer I've implemented a transaction log based on triggers and stored procedures. The transaction log, triggers and the stored procedures however I implemented only postgresql as that was the customer's database. It's easy to implement ms sql or oracle version though. It works perfectly, much much much faster than RMI, recovers if the sync process is interrupted , etc. My goal was to implement this mechanism using entity engine level triggers and eventually commit it, but unfortunately still pretty busy with other things so we don't have resources that can be dedicated to work on that task at the moment, we're trying to work out the world financial crisis :)

So if you find what i say reasonable you could go ahead with the triggers and SPs. For that you need database that supports triggers - so mysql won't work :)

That was just the first part. 

The second part is to identify all the tables that you need to synchronize. Some of them will be only pulled, some of them  pushed only and some of them synced in both directions. Next you need to test, reset the database and  test again and again until you identify the correct list of the tables so your sync process doesn't end up with FK  insert / update errors. That is pretty easy but time consuming task - it takes few days to complete :)

So that's all I can say for now, without getting your bored with details :)
{quote}


> Issues with EntitySync
> ----------------------
>
>                 Key: OFBIZ-3333
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-3333
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework, specialpurpose/pos
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>
> This is an umbrella task to groups all issues related to the synchronization process.
> A subtask will be created for each identified issue.
> I selected framework and POS as affected components, because for the moment the synchronization process is mostly used to sync POS terminals. But it could be used for other needs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.