Hello. I have been using symmetric for over a year and i have discovered weird conflict resolutions.
I have one central node and several nodes that need to be replicated. ALL the databases should be identical, the sync should be bi directional. Node one modifies something, Node two modifies something, the server receives it and should leave everything consistent in the three places, nodes and server, all the same.
I cannot figure out what conflict resolution to use. I have tried them all. I want to use USE_CHANGED_DATA that resolves with the newest one. That would be ideal.
Doing some debuggin i found out that symmetric actually send the correct information to the node but the node ignores the resolution and the local db stays inconsistent!
When I used USE_TIMESTAMP and NEWER_WINS everything was ok, but when i manually deleted from the central db, the node that created that item doesnt delete it, it ignores the delete :/
I really dont know what else to try. What configuration should be used in a bi directional context where all the databases should stay the same?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It sounds like you are close. You want to setup a conflict that runs on the central server by setting it as the target_node_group_id. Detect with USE_TIMESTAMP, resolve with NEWER_WINS, and put the timestamp column name in the detect expression. A ping back of SINGLE_ROW.
The part I don't understand is where you describe that it does appear to sending the resolving row, but it's not loading. And then you further tried to delete the row and it didn't sync. It almost sounds like the primary key for that table is different or missing on those two nodes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only problem with this is that if i delete a row in one node, then the other node doesnt delete that row. If you check the code in the source of Symmetric you can see that in the case of DELETE and NEWER_WINS there is a comment "//nothing to do..." But there is stuff to do! I dont know why they made it this way and i cannot seem to find a way to resolve the conflicts myself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Eric. Did you have time to look at my problem?
The partial solution that we found was to implement a logic delete, we add a column that indicates if a row was deleted. So this column gets synchornized and then the node that created/edited this row delets it. Its not very elegant, but we couldnt find a way to make the delet's work. If not, there are rows in the nodes that never get deleted and the databases stay inconsistent.
Could I extend a class? Or reimplement something? I could'nt find any extension that allowed me to correct this.
Thank you very much!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WHEN I USE timestamp it showing some error like
org.jumpmind.exception.ParseException: Could not parse TIMESTAMP with a value of 2017-02-27 03:24:05 for purposes of conflict detection
at org.jumpmind.symmetric.io.data.writer.DefaultDatabaseWriterConflictResolver.isTimestampNewer(DefaultDatabaseWriterConflictResolver.java:102)
at org.jumpmind.symmetric.io.data.writer.AbstractDatabaseWriterConflictResolver.needsResolved(AbstractDatabaseWriterConflictResolver.java:57)
at org.jumpmind.symmetric.io.data.writer.AbstractDatabaseWriter.write(AbstractDatabaseWriter.java:179)
Last edit: Manoj 2017-02-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I assume there is an update occurring from the second node to trigger the conflict with the delete, is this a safe assumption? If so is the delete happening prior to the update? In this scenario it seems like the issue would be that the update wins on the target but is not being handled properly back on the node that sent the delete.
Manoj,
Is this column a timestamp type in your database?
Thanks
Josh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello. I have been using symmetric for over a year and i have discovered weird conflict resolutions.
I have one central node and several nodes that need to be replicated. ALL the databases should be identical, the sync should be bi directional. Node one modifies something, Node two modifies something, the server receives it and should leave everything consistent in the three places, nodes and server, all the same.
I cannot figure out what conflict resolution to use. I have tried them all. I want to use USE_CHANGED_DATA that resolves with the newest one. That would be ideal.
Doing some debuggin i found out that symmetric actually send the correct information to the node but the node ignores the resolution and the local db stays inconsistent!
When I used USE_TIMESTAMP and NEWER_WINS everything was ok, but when i manually deleted from the central db, the node that created that item doesnt delete it, it ignores the delete :/
I really dont know what else to try. What configuration should be used in a bi directional context where all the databases should stay the same?
It sounds like you are close. You want to setup a conflict that runs on the central server by setting it as the target_node_group_id. Detect with USE_TIMESTAMP, resolve with NEWER_WINS, and put the timestamp column name in the detect expression. A ping back of SINGLE_ROW.
The part I don't understand is where you describe that it does appear to sending the resolving row, but it's not loading. And then you further tried to delete the row and it didn't sync. It almost sounds like the primary key for that table is different or missing on those two nodes.
Thanks for answering Eric. The best conflict resolution that we found(and we tried all of them) was the following:
server-node USE_TIMESTAMP NEWER_WINS REMANING_ROWS
node-server USE_TIMESTAMP NEWER_WINS REMANING_ROWS
The only problem with this is that if i delete a row in one node, then the other node doesnt delete that row. If you check the code in the source of Symmetric you can see that in the case of DELETE and NEWER_WINS there is a comment "//nothing to do..." But there is stuff to do! I dont know why they made it this way and i cannot seem to find a way to resolve the conflicts myself.
Hello Eric. Did you have time to look at my problem?
The partial solution that we found was to implement a logic delete, we add a column that indicates if a row was deleted. So this column gets synchornized and then the node that created/edited this row delets it. Its not very elegant, but we couldnt find a way to make the delet's work. If not, there are rows in the nodes that never get deleted and the databases stay inconsistent.
Could I extend a class? Or reimplement something? I could'nt find any extension that allowed me to correct this.
Thank you very much!
WHEN I USE timestamp it showing some error like org.jumpmind.exception.ParseException: Could not parse TIMESTAMP with a value of 2017-02-27 03:24:05 for purposes of conflict detection at org.jumpmind.symmetric.io.data.writer.DefaultDatabaseWriterConflictResolver.isTimestampNewer(DefaultDatabaseWriterConflictResolver.java:102) at org.jumpmind.symmetric.io.data.writer.AbstractDatabaseWriterConflictResolver.needsResolved(AbstractDatabaseWriterConflictResolver.java:57) at org.jumpmind.symmetric.io.data.writer.AbstractDatabaseWriter.write(AbstractDatabaseWriter.java:179)Last edit: Manoj 2017-02-27
Inaki
I assume there is an update occurring from the second node to trigger the conflict with the delete, is this a safe assumption? If so is the delete happening prior to the update? In this scenario it seems like the issue would be that the update wins on the target but is not being handled properly back on the node that sent the delete.
Manoj,
Is this column a timestamp type in your database?
Thanks
Josh
Does anyone know other solution besides logical deletes ?
I have the same issue.
Last edit: EMILIO E. R. A. 2017-11-16