0

Suppose we have a Cache configured with a write-behind CacheWriter. Let's assume we put some object in the cache and later on the object is removed because of an eviction policy.

What's is guaranteed regarding writing? More precisely, is write() event guaranteed to happen for that object, even though it was removed before it "had a chance" to be written?

Thanks!

IsaacLevon
  • 2,260
  • 4
  • 41
  • 83

1 Answers1

1

No, write() is not guaranteed to happen. In a write-behind case, all writes are stored in a queue while some background threads read from that queue to update the underlying SoR (System of Records, i.e.: your database). That queue can be read or modified by other threads concurrently reading or modifying the same cache.

For instance, if a put() happens on a certain key, write() enqueues the command. If before one of the background thread had the chance to consume the write command before remove() happens on that same key, the write command can be removed from the queue (note the 'can' here). There are other similar optimizations that can take place ('can' again), those can change and new ones can be added in any minor version as this is all considered an implementation detail, as long as the data served by Ehcache follows its general visibility guarantees.

This means Write-Behind, and more generally all CacheWriters must not be used for any form of accounting, if that's the use-case you had in mind.

Ludovic Orban
  • 396
  • 1
  • 6
  • I still can listen to a remove event, right? My end goal is to sync all the data (eventually) to the DB. I don't mind that the DB will not be synced with the cache immediately, but I don't want to lose data. – IsaacLevon Jul 25 '19 at 13:40
  • If you goal is to sync you cache with your DB, then just implement `CacheLoaderWriter` and let Ehcache do the rest, as it does guarantee that data will end up being written to the database. That is, omitting any crash of the JVM running Ehcache, of course. Unless you're running clustered. – Ludovic Orban Jul 26 '19 at 12:40
  • Yeah, that's exactly what I did (Implementing `CacheLoaderWriter`). I probably confused you by writing `CacheWriter` (?) – IsaacLevon Jul 28 '19 at 08:09
  • What isn't clear to me now is how these two statements exist together: (1) "This means Write-Behind, and more generally all CacheWriters must not be used for any form of accounting" (2) "as it does guarantee that data will end up being written to the database". Can you please elaborate on that? – IsaacLevon Jul 28 '19 at 08:11
  • My guess is that it means (1) data can be lost. (2) cache may be inconsistent with the DB - So don't use this solution if you're implementing something that needs to be transactional (like bank accounts operations) – IsaacLevon Jul 28 '19 at 08:17
  • Re. (1) data cannot be lost, for as long as the JVM running the write-behind cache doesn't crash, or for as long as the cluster is healthy if you're running clustered. Re. (2) you are correct: there's always going to be a delay between when some data was written to Ehcache and when the data ends up in the SoR. This is a well-known trade off of using write-behind: only ever access your data via the cache or risk reading a stale SoR. – Ludovic Orban Aug 01 '19 at 05:58