Sorry, my english it's a little bit limited... I will try to explain myself again:
When I said that it "crashed" I wanted to say that suddenly the program doesn't work like it usually does. When the client inserts a row, this row is modified later by other program that puts true into a field to specify it's been "processed" (for say "processed").
And when the concurrency occurs the client reinserts the row and this field returns to false. Also, the users' table (what is also upload/download) crashes and the data is stored incorrectly on the server but not on the clients.
I will explain it all summed up:
1. two clients sync at the same time.
2. the inserted rows is processed by other program and it changes into true the value of the field "processed"
3. one of these clients synchronizes again another row. This client has problems because concurrency has damaged the server's database.
4. the row, after synchronizing, it synchronizes again with the client.
...
X. whatever sync new row of this client put the field of old rows syncs after concurrency to false.
Each new row of the client synchronized will change the previously synchronized after the concurrence rows' field "processed" into false.
I put a visual explanation:
client
server client
A----o
A----o B----o
A----o
B----o B----o
A----o
A----o B----o
A----x =====(new)========> A----x
B----x <=====(new)======== B----x
(concurrency)
Other program updates the row server changing the "processed" value into true but the client don't update.
client
server client
A----o A----o
B----o
A----o B----o
B----o
A----o A----o B----o
A----x A----o
B----o
B----x
new sync
client
server client
A----o A----o
B----o
A----o B----o B----o
A----o A----o
B----o
A----x ====( incorrect )=====> A----x <---- Reinsert
B----o =====(update)======> B----o
A----x =====(new)========> A----x
....
(not concurrency)
B----x <=====(new)======== B----x
As you can see, on one of the clients the rows are reinserted and it never updates the local data.
I hope I have explained better the scenario.
