Confusion regarding caches' prop readWrite and mutability

[bruderj15]

Hello.

According to the docs here:
The cache will be treated as a read/write cache, meaning objects retrieved are not shared and can be safely modified by the caller, without interfering with other potential modifications by other callers or threads.

I think this is highly confusing.
Usually:

• Read-Cache: Query once, read multiple times
• Write-Cache: Write into buffer, flush later
• R/W-Cache: Do both, often without invalidation on writes (reading buffered writes)

How does the latter entail that [...] objects retrieved are not shared and can be safely modified by the caller [...]?
This is just a wording thing.

My actual problem is modification - the data in the cache seems mutable (contrary to what is stated in the docs):

@CacheNamespace
class TaskMapper { @Select List<Task> findTasks() ... }

class TaskService {
  private TaskMapper taskMapper;  

  List<Task> getTasks() {
    List<Task> tasks = taskMapper.findTasks();
    foo(tasks); // effectful modification (side-effect)
    return tasks;
  }
}

Here, if foo(..) is not idempotent, TaskService::getTasks won't be either.

If we set the readWrite prop to false (previously defaulted to true):

@CacheNamespace(readWrite = true)
class TaskMapper { @Select List<Task> findTasks() ... }
// ...

Then TaskService::getTasks is idempotent, suggesting some weird connection between immutability and the (write) cache behavior.
There shouldn't at all - we didn't write anything here.

Is there an explanation?

[harawata]

Hello @bruderj15 ,

I think you understand the doc correctly, but there also is a NOTE on that page:

Second level cache is transactional. That means that it is updated when a SqlSession finishes with commit or when it finishes with rollback but no inserts/deletes/updates with flushCache=true where executed.

Your code probably modifies the result before it gets cached.
If you call taskMapper.findTasks() beforehand (during startup, for example, just to cache unmodified results), modification by foo() won't affect the already-cached objects.

[bruderj15]

You're right!
Indeed foo() was called within the same transaction - therefore modifying the data before actually storing it in the cache.

I was missing the NOTE, thank you @harawata!