When configured with ATTRIBUTE granularity, a single HttpSession is mapped to N+3 cache entries. 2 entries are used for session meta data (and will not be addressed here). 1 entry is used to store attribute names, and a cache entry per session attribute.
The intention was to minimize the the payload for a typical read-heavy usage, where only a small subset of attributes would ever be added/removes/updated in a given request.
Adding or removing a session attribute involves updating the cache entry containing the set of session attributes, and creating or removing the attribute specific entry.
Updating a session attribute on requires updating the attribute specific entry, since the set of attributes has not changed.

There are a few problems with this approach:
1. Each cache entry requires the overhead of the cache key
2. When configured with a non-transactional cache, updating M session attributes requires M cache operations.
3. The existing mapping is prone to cross-entry data integrity issues, which can affect non-transactional use cases

Several releases ago, we optimized the cache entry containing session attribute names using Infinispan's support for the Map.compute(...) operation, such that updates only need to marshal changes, i.e. adds/removals. We can use the same concept to support a single Map<String, MarshalledValue> such that only adds/removals/updates needs to be marshalled.