Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi

I have som questions about write-behind. I hope someone has been on this path and have some suggestions/answers for me. Heres me case.

I have 2 application servers that will share a terracotta clustered ehcache writebehind cache. The write behind cache will be writing with config writeCoalescing="true". It will try to aggregate stuff for me.

Now if app01 have an entry to write with key 1 and count 10 for example, and app02 have an entry to write with key 1 and count 11.

Both appservers and there write behind threads will try to write these values. If I have some bad luck app02 write his value first and then app01 writes his value. Then I have the wrong value in my db.

I guess that when write behind desides its time to write the value in the queue is final and dont reflects changes made after that.

Are there any solutions to this? One thought/wish was that I could have a writer on just one applicationserver and the writebehind queue was visible over the cluster.

Does anyone done something similar to this?

On a single node, write behind will handle things in a consistent state with the cache. Order should be preserved alright. Now if two nodes do modify the data, it could indeed be that one node, who's value has been overwritten by another node already, gets to write to the underlying SoR only _after_ the other (more up-to-date) value has been written indeed.
You'll want some versioning scheme to avoid overwrites. In the example of the counter, if applicable of course, you could only write the new value as long as it is greater than the current one.

Hi thanks for the quick answer.

The count example is simplified, we have both + and - activities on the aggregate, so checking the number is not an option.

As for versioning, this may be a way to go, if we every time we update the number increase a version number in the cache, then we may know if to update or not.

Any other good suggestions?