Currently, all data stored into the second level cache is handled the same way. The data is first disasembled into a state array, that array is deep copiedand that deep copy is put into the cache. The reverse is done for reading from the cache. For example, take an entity named ZipCode:
Currently, storing that into the second level cache would:
disasseble the ZipCode into its basic state as an array ([code,plus4])
deepCopy that array
#push that array copy on to the cache
All cacheable data that is mutable needs to continue to be handled this way.
However, for immutable (aka "reference") data there are more efficient ways to store the information. Within immutable data there is still a further distinction we need to make with regards to associations. Does the reference data define associations (many-to-one, etc)?
In the simpliest case, consider reference data with no associations like we have above with ZipCode. Here it is feasible to store the ZipCode reference directly into the cache. With a caveat... the developer needs to understand that in memory changes to this ZipCode would now directly "write through" to the cache. Dangerous.
At the other extreme for cacheable reference data would be reference data with one or more associtions to mutable (transactional) data. Here we absolutely would not be able to directly write the object instance out to the second level cache region. We clearly need the disassembly. However, the deepCopy is actually unnecessary in this case.
In between we have a gray area with regard to cacheable reference data with associations to nothing but other immutable reference data, such as the case of ZipCode with reference to the State it belongs to:
Here it would be possible to cache ZipCode "whole". Not sure yet though if that is what we want.