Cache on EhCache 2.10.2. Replication is not asynchronous (replicateAsynchronously = false) on two servers.

It turns out the following situation:

  1. HTTP request comes to the first S1 server
  2. S1 does not find the object in the cache and loads it from the database with the state "A" and puts it in the cache
  3. In S1, the state of the object is changed to "B", the object is saved in the database and put in the cache
  4. S1 responds well to a request.
  5. From the outside comes the next request and gets into the second server S2
  6. S2 finds in the cache an object with the state "A"
  7. S2 responds with an error to the request, because the object should have had state "B"
  8. The object in the cache is updated to the object with the state "B"

The problem arises from the fact that when we make a put to the cache, we get control back when the deserialized object is sent to another server, but not when it is deserialized there and is actually updated. Those. state "B" may have time to upgrade to 6 points, but maybe not.

Can I somehow configure EhCache to block put to the end?

Maybe EhCache to replace something else or completely redo the approach?

Note. The requests are consecutive, the second request (p.5) comes only after receiving the answer to the first (p.4). For example, the first request is user authentication and if it is successful, then a second request is made - getting information about the user. If, say, the time between p. 3 and p. 8 is 100ms, then the situation would be corrected by the response delay (p. 4) for these 100 ms, since by the time of the second request, the already needed status would be “B”.

  • I'm afraid it's just physically impossible. If you are caching data, you must either be prepared for a non-consistent state, or not be cached. In fact, you get two systems (DB and cache) that cannot be atomically updated together, so you cannot solve this problem. You can make it so that point 4 will be executed only after updating the cache on all servers, but in fact it will only give you problems, and will not do anything with the original one. - etki pm
  • @Etki what problems can there be if just the answer to the first request will be a little longer? - Russtam
  • That client who requests, it does not throw. All the rest - throw, because the bug will turn into a heisenbag. You understand that if you enable synchronous replication, you will simply delay the client's response time, and you will not do anything with the problem itself? - etki
  • @Etki Apparently I didn’t explain well. Item 5 is strictly after the 4th. These are two consecutive requests. - Russtam
  • You can guarantee the sequence of requests only if you have one client. - etki

0