Updating one doc twice within 0.3 seconds are considered conflict and result in huge delay (3-8 seconds)?

[SeanDev]

Hi all,

I've been syncing two types of docs to perform registered voting. Where there are two types of docs. The userprofile type, one doc per user; and the votingsession type, one doc per voting session.

The userprofile doc will only be created, but never updated. Each time I create a userprofile doc, it takes about 1 second or so for all devices to sync this doc.

The votingsession doc, on the other hand, will be frequetly updated (2 times per seconds), because all related-users are voting in one voting session (therefore each user can see who has already voted, and who has not). Creating a votingsession doc takes a second to sync, but sometimes updating it will take 4 to 10 seconds, which is not acceptable.

Actually, there are two scenarios:

1. update twice with interval of 10 seconds, the syncing time is still about 1 second
2. update twice with interval of 0.3 second, the syncing time is 4 to 10 seconds, and in sync_gateway log, there are ocational gaps:
   
• Gap set 1:
• 11:49:26.584586 Cache: SAVING #1110

  11:49:26.585372 CRUD: Stored doc "vs:votingsession1" / "119-b89b6e406ac0a70d9ee2d62713b59e5c"

  11:49:26.585407 HTTP+: #542:     --> 201   (5.1 ms)
  ----1 seconds GAP----

  11:49:27.442408 Cache: Received #1110 after 858ms ("vs:votingsession1" / "119-b89b6e406ac0a70d9ee2d62713b59e5c")

  11:49:27.442429 Cache:   Deferring #1110 (1 now waiting for #1109...#1109)

  11:49:27.442441 Cache: Received #1110 after 858ms ("vs:votingsession1" / "119-b89b6e406ac0a70d9ee2d62713b59e5c")
  ----3 seconds GAP----
  

  11:49:31.107879 HTTP:  #543: PUT /votings/_local/d4c62545bf68b2cf2f6916c66c9731ea335f4e55  (as user2)

  11:49:31.108300 HTTP+: #543:     --> 201   (0.8 ms)

  11:49:33.069765 WARNING: changeCache: Giving up, accepting #1110 even though #1109 is missing -- db.(*changeCache)._addPendingLogs() at change_cache.go:320
  
  
• Gap set 2:
• 11:49:33.671838 Changes+: MultiChangesFeed waiting...   (to user1)

  11:49:33.671849 Changes+: Waiting for "votings"'s count to pass 87
  ----5 seconds GAP----
  

  11:49:38.240364 HTTP:  #547: PUT /votings/_local/c0dc8032a17489187a3347f67a892b9ce23d1f7f  (as user2)

  11:49:38.240858 HTTP+: #547:     --> 201   (1.1 ms)

  11:49:38.650752 HTTP:  #548: PUT /votings/_local/f614ee31fd7af53c3564a447b5131a10557fefbd  (as user1)

  11:49:38.651250 HTTP+: #548:     --> 201   (1.1 ms)

Now, why would two updates in 0.5 seconds considered conflict? Why would conflict result in huge delay? 

After all, are there any kind of best practice for updating docs, like don't update the doc in less than 1 second?

[Jens Alfke]

Now, why would two updates in 0.5 seconds considered conflict? Why would conflict result in huge delay? 

It’s not a conflict causing the delay & warning; it’s a missing update notification from the database server. Andy on the Sync Gateway team has been investigating the cause of missing sequences, and re-implementing some of the code to track sequences more robustly. This tends to happen more often on a highly loaded database server.

sometimes updating it will take 4 to 10 seconds, which is not acceptable.

We do intend to figure out and fix this glitch, but Couchbase Mobile is not intended to be a real-time system, so that sort of latency can occur.

The votingsession doc, on the other hand, will be frequetly updated (2 times per seconds), because all related-users are voting in one voting session (therefore each user can see who has already voted, and who has not).

I don’t know the details of your application, but having one document that’s frequently updated by multiple users is usually not a good design, because it’s very prone to conflicts. In general it’s better for each user to have their own document that they update; then you can use a query to group together the related documents and produce the aggregated result.

—Jens

[SeanDev]

Thanks, Jens.

I'm not yet familiar with groups, but your suggestion looks great and would solve this voting scenario better.

I'll definitely redesign this voting part in your way.

-Sean