What are semantics associated with the Concurrent Lock?
A Concurrent Lock in Terracotta defines a transaction boundary but gives no visibility or correctness guarantees. There is no conversation with the Terracotta server – but the “Terracotta transaction” begins when the concurrent lock is acquired and ends when the concurrent lock is released and all mutations within are batched and committed to the Terracotta server. So with a concurrent lock, 2 threads could read or write to a shared object graph concurrently (i.e no correctness guarantees) Defining no lock implies GETS/READS might work but there is no guarantee of correctness (in that one might be able to get stale or partially committed data) – but then you would not be able to write to it. With Concurrent Lock in place, GET/READS/WRITES can all work with no guarantees around correctness.
