0
votes

I am using Spring-Boot, Spring-Data/JPA with Hazelcast client/server topology. In parts of my test application, I am calculating time when performing CRUD operations on the client side (the server is the one interacting with a relational db). I configured the map(Store) to be write-behind by setting write-delay-seconds to 10.

Spring-Data's save() returns the persisted entity. In the client app, therefore, the application flow will be blocked until the (server) returns the persisted entity.

Would like to know is there is an alternative in which case the client does NOT have to wait for the entity to persist. Was under the impression that once new data is stored in the Map, persisting to the backed happens asynchronously -> the client app would NOT have to wait.

Map config in hazelast.xml:

<map name="com.foo.MyMap">
    <map-store enabled="true" initial-mode="EAGER">
        <class-name>com.foo.MyMapStore</class-name>
        <write-delay-seconds>10</write-delay-seconds>
    </map-store>
</map>

@NeilStevenson I don't find your response particularly helpful. I asked on an earlier post about where and how to generate the Map keys. You pointed me to the documentation which fails to shed any light on this topic. Same goes for the hazelcast (and other) examples.

The point of having the cache in the 1st place, is to avoid hitting the database. When we add data (via save()), we need to also generate an unique key for the Map. This key also becomes the Entity.Id in the database table. Since, again, its the hazelcast client that generates these Ids, there is no need to wait for the record to be persisted in the backend.

The only reason to wait for save() to return the persisted object would be to catch any exceptions NOT because of the ID.

1
The save() method is returning you the persisted entry as it may (in general) have been modified by the persistance system -- such as an auto-generated @Id column on an RDBMS - Neil Stevenson
According to this docs.hazelcast.org/docs/3.4/manual/html/map-persistence.html the map.put operation should return without waiting for the async store when write behind is configured. And this is what should be used. This sounds like a bug or you configured something completely different than I think. Please confirm that you configured write-behind as describe in the link above. Also, can you try the behavior with just Hazelcast (without spring data)? - Jens Schauder

1 Answers

0
votes

That unfortunately is how it is meant to work, see https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/CrudRepository.html#save-S-.

Potentially the external store mutates the saved entry in some way.

Although you know it won't do this, there isn't a variant on the save defined.

So the answer seems to be this is not currently available in the general purpose Spring repository definition. Why not raise a feature request for the Spring Data team ?