How can I ensure the data is modified correctly?

[seto]

I have two thread trying to modify a queue in the cache.

The 1st is reading the queue, adding object to it and putting back .

The 2nd is reading the queue, polling object from it, and putting back. And it's a iterative operation.

Now, the 2nd overwrite the adding operation from 1st.

Because the 2nd read the old queue. And overwrite it.

I want to avoid the 2nd reading the queue, while the 1st modifying the queue.

I can't use thread lock. Because the cache is distributed clustered.

How can I avoid the overwrite by threads?

Which transaction should I use, pessimistic or optimistic?

I tried both it seems that both are committed without any exception thrown.

[seto]

OIC.

I should use write skew check, repeatable read, optimistic lock and versioning.

[william.burns]

To be honest you use optimistic when you don't plan on having very few concurrent writes on the same key.  If you have a lot of concurrent writes overlapping you should use pessimistic locking.  You can check out the section [1] for more details and how to use the various modes.

[1] Infinispan 9.0 User Guide

[seto]

I tried pessimistic lock. It seems that it doesn't lock the key. The data is still overwlapped.

What will one thread locking a key and another thread trying wo write happen? Wait or throw exception? It seems it doesn't work for me. Neither wait, nor throw exception.

[william.burns]

It sounds like you are only locking the key for the duration of the write, but you need to lock it during the read and write.  If you look closely it shows some code of how to lock it manually or when doing a read with pessimistic locks.

cache.getAdvancedCache().withFlags(Flag.FORCE_WRITE_LOCK).get(key);

This will lock the key and read it at the same time.  Then you can perform the write knowing that no one else can acquire the lock.  If you do this for both operations then neither will see the value in an outdated state.

[seto]

If I lock the same time it read. It will work.

But if I read key and lock, then the lock may occurs between the commit. Then it won't throw an exception.

And the most important is the Transaction Lock Mode is cache level. If it can be apply to transaction level. Then it will be great.

Because some of my operations are with high concurrency requirement. The optimistic lock will be better for that case.

And also I encapsulate the Infinispan as the data layer of my game server. I have to use only 4 caches.

One for distributed id->Object, one for distributed key->id. And the other two for local.

If the transaction lock mode can be transaction level, it would be great.