Write-behind CachingEventSourcingRepository implementation

Imported from Google Groups
1

Hello all,

Unless I’m mistaken the CachingEventSourcingRepository implementation is somehow a write-through implementation. It means it stores the data into the cache then tries to updates the event store. If the event store write fails for whatever reasons, there is a compensation to remove the cached data.

This might create to me potential issues if between the read and the remove, another concurrent client tries to do a read without any specific locking.

Don’t you think it might make sense to implement the way to choose the strategy? Personally I would be more interested in an approach where the cache is updated after the event store was updated.

What’s your opinion? Is there anything I’m missing?

Regards,
teivah

2

Hi Teivah,

this approach is deliberate. The caching is just meant to speed up loading of an aggregate. Using the cache as a write-cache is a good way to get into trouble ;-). Memory is not a good place to save things. So when publishing events, for most applications, it’s essential to guarantee that the events that cause changes are also saved. Also, storing the events in the event store is the way to publish changes to other components. Waiting until a certain timeout has occurred wouldn’t make a lot of sense.

Cheers,

Allard