The SnapshotBackedWriteTransaction has no internal synchronization and thus is not safe for multiple-thread access, concurrent or not. This is the intention for performance reasons - let the client synchronize it if they need to (like the JDK collections classes do).

ShardWriteTransaction actor receives write/merge/delete/ready messages via akka and, internally, it has a SnapshotBackedWriteTransaction that each message modifies. While messages are not sent concurrently by akka and updates in the SnapshotBackedWriteTransaction will not occur concurrently, they may be sent serially by multiple akka threads.

One aspect of multi-threading in java and the java memory model is ensuring that writes done one thread are published or made visible to other threads. This requires some form of synchronization (i.e. synchronized block, java.concurrent.Lock, volatile keyword, final keyword on instance fields, thread enter/exit ...).

We could simply synchronize on the SnapshotBackedWriteTransaction instance but this carries the exclusive lock overhead that we don't need as we won't have concurrent access. Instead, we could use a separate volatile variable as a read/write memory barrier "guard" for publishing writes across threads, as explained here by this snippet in Java Concurrency in Practice:

"The visibility effects of volatile variables extend beyond the value of the volatile variable itself. When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to the volatile variable become visible to B after reading the volatile variable."