I should use write skew check, repeatable read, optimistic lock and versioning.
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  for more details and how to use the various modes.
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.
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.
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.
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.