Q:

Correct use of mutable mongodb entities in reactive (webflux) application

Current spring-data-mongodb project uses mutable entities to load state from database even in reactive application. It is considered a bad practice and I can find some issues even in the spring-data-mongodb project itself. For example code snippet from ReactiveMongoTemplate:
protected <T> Mono<T> doSave(String collectionName, T objectToSave, MongoWriter<Object> writer) {

    assertUpdateableIdIfNotSet(objectToSave);

    return createMono(collectionName, collection -> {

        T toSave = maybeEmitEvent(new BeforeConvertEvent<T>(objectToSave, collectionName)).getSource();

        AdaptibleEntity<T> entity = operations.forEntity(toSave, mongoConverter.getConversionService());
        Document dbDoc = entity.toMappedDocument(writer).getDocument();
        maybeEmitEvent(new BeforeSaveEvent<T>(toSave, dbDoc, collectionName));

        return saveDocument(collectionName, dbDoc, toSave.getClass()).map(id -> {

            T saved = entity.populateIdIfNecessary(id);
            return maybeEmitEvent(new AfterSaveEvent<>(saved, dbDoc, collectionName)).getSource();
        });
    });
}

As you can see entity.populateIdIfNecessary(id) is mutating entity object on another thread, which is considered  a bug in multithreaded application, unless you use entity where all setters are synchronized.
What is the correct and recomended practice to deal with concurrency issues using mutable entities with reactive mongodb interface?
Consider this example:
reactiveMongoOperations.findById("id2", Customer.class) // calls Customer setters on thread1
  .zipWith(reactiveMongoOperations.findById("id2", Account.class)) // calls Account setters on thread2
  .map(t -> perform(t.getT1(), t.getT2())); // access objects on thread2

To make this code safe, you need to have immutable Customer and Account classes (which spring data mongodb desnot support), or all setter must be synchronized/volatile witch makes your code very thread-aware and error prone.

A:

I just found similar question with the answers about project reactor and memory model Project Reactor and the Java memory model . So it seems that if you are not using parallel operator, memory consistency is guaranteed using memory barriers (volatile keywords). 

