Improve concurrency when synchronizing #696
Replies: 1 comment 9 replies
-
TransactionWhat's the benefit to have one transaction per table (for reading) ? That's being said, should we consider to be able to remove transactions when reading changes (at least through an option or a mechanism like interceptors ?) Regarding the issue #695, should we also consider to be able to remove transactions for writing as well ? For the read lock, you have the option to set an I don't know if removing transactions will have more benefits than drawbacks, but adding an option to remove transaction during a particular step should not be too complicated, I guess. TimestampFor the timestamp, in a nutshell, this value does not have any relationship with the in progress transaction.
There is no relationships between transactions and timestamp, because (especially on SQL Server) we are not using the |
Beta Was this translation helpful? Give feedback.
-
-> Now if another user syncs then applying his changes may fail due to a transaction deadlock.
We solved this by creating a separate version of dotmim.sync that uses one transaction per table when fetching changes.
This does have the downside, that you may see records that you were not supposed to see.
eg.
Order
,OrderDetail
tables.OrderDetail
has foreign key toOrder
. Therefore you have to synchronzie these tables in the orderOrder
OrderDetail
Now using our approach you could end up with an
OrderDetail
record sent to your client, that points to anOrder
that was not synchronized to your device yet.The best option, in this case (and in my humble opinion), would be to take the "currentTimestamp" (taken the first instant the sync request receives the server) and, instead of using transactions for selecting changes, create a separate transaction for each table and
select all changes where timestamp > lastSyncedTimestamp && timestamp < currentTimestamp
That would give you the best of both worlds:
@Mimetis what do you think?
Beta Was this translation helpful? Give feedback.
All reactions