What is a write conflict?

The core feature of p5.party is the shared object: a data object that is kept in sync between all instances of the sketch. When one client sets a value on a shared object, the change is immediately updated on the local object. The value change is also sent to the server and then broadcast to all the other clients. It takes some time—usually 50 to 500 milliseconds, depending on network quality—for each client to be updated. This delay introduced the possibility that a client will write to a shared object and then receive a change from another shared object that conflicts and overwrites the local change.

When do write conflicts occur?

A write conflict occurs when two clients try to write to the same shared object at nearly the same time.

Here, “nearly the same time” means that a client writes while another client’s write is still in transit.

Can write conflicts occur even if the writes are to different properties?

It makes sense that if two clients set the same property—like shared.fruit—at once, only one of the values prevail. Unfortunately, the problem is more broad than that. A data conflict occurs even if the clients are setting different properties if they are on the same shared object. If client A sets shared.fruit to "apple" at the same time that client B sets shared.animal to "bear" one of those changes will be thrown out.

What happens during a write conflict?

The short answer:

One value is thrown out.

The medium answer:

When two clients write to the same object at the same time, their changes race. The winning change is sync’d. The losing change is thrown out.

The long story:

Imagine two clients—A and B—set shared.fruit at nearly the same time.

Client A sets it to "apple" and client B sets it to "banana".
Both A and B immediately update the fruit property of their local shared object.
Both A and B send a message to the server about the change.
Let's assume client A's message gets to the server first. The server will broadcast shared.fruit = "apple" to all of the clients.
Then client B's message will get to the server. The server identifies that this change is a conflict and throws it away.
Client B then receives the message that fruit should be "apple" and overwrites the local value accordingly.
Client A never knows that Client B wanted to set fruit to "banana".
On client B fruit is briefly "banana" before settling on "apple".
Now both clients are in sync, but Client B’s change is lost.

Is that the worst that can happen?

Losing one of the changes is the worst that should happen, but sometimes data conflicts can lead to broken client-server connections. This usually only occurs when there are lots conflicts happening at once.

How do I avoid data conflicts?

A conflict happens when multiple clients write to the same shared object at nearly the same time. All of those things need to happen together, so there are many ways you might avoid conflicts.

You won’t have a conflict if:

a single client writes to a shared object frequently
multiple clients read from a shared object at the same time