[
https://issues.apache.org/jira/browse/OFBIZ-3333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854598#action_12854598
]
Jacques Le Roux commented on OFBIZ-3333:
----------------------------------------
Here is a quote from a Deyan's message he sent us personnally
{quote}
So about the transaction log:
I have a table called TRANSLOG with the following structure:
CREATE TABLE translog
(
id bigserial NOT NULL,
"table" character varying(30) NOT NULL,
operation character varying(6) NOT NULL,
"statement" character varying NOT NULL,
created_on timestamp with time zone NOT NULL DEFAULT now(),
CONSTRAINT id_fk PRIMARY KEY (id)
)
Records in the TRANSLOG table are being inserted by the triggers for the table
we are "watching" for changes on INSERT, UPDATE and DELETE.
The STATEMENT column contains executable SQL statement which is generated by
the trigger function. The following screenshot shows some data in the TRANSLOG
table: (see attachments)
So every time some database action is performed on the tables we are "watching"
we get a TRANSLOG entry.
Each translog entry has a sequence ID. So when we want to PUSH that transaction
log to the main server we actually execute the statements ON the main server.
We execute the statements wrapped in a transaction which gets rolled back if an
error has occured.
The translog push gets invoked by a stored procedure which gets called by a
scheduled reoccuring job in ofbiz.
For each sync SP execution we store a record in a table called
TRANSLOG_EXEC_LOG . There we keep the currently reached translog_id so we know
from where to start the next time
when the sync SP is invoked.
So in general that's the mechanism. Pretty simple to implement, pretty simple
to troubleshoot and pretty error resistant . Here's the screenshot of
TRANSLOG_EXEC_LOG: (see attachments)
The result message could be either OK or the DB error message - either a
constraint error or some other error. We always know which was the last
successfully executed statement (
last_command_id ). If there is an error then we know at which statement the
error has happened - the next after the last successful one.
That's all in general.
{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
> Attachments: screenshot-1.jpg
>
>
> 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.
