Skip Java immutable objects in session when processing the accessed attributes [SPR-11738]

[spring-projects-issues]

Dongqing Hu opened SPR-11738 and commented

String, Integer, Long, Boolean... Such typed value objects can be skipped from updating in ServletRequestAttributes#updateAccessedAttributes() , or skipped from being added to #sessionAttributesToUpdate via #getAttribute()

This is good optimization when the session is full of values. Do less serialization and I/O (sometimes none) in session management.

In which of the two methods is it better to place the "skip" logic?

---

No further details from SPR-11738

[spring-projects-issues]

Dongqing Hu commented

GitHub pull request #533.
#533

[spring-projects-issues]

Dongqing Hu commented

Also I see 4 tests failed in the public repository (spring-beans). Maybe you need to take a look.

[spring-projects-issues]

Juergen Hoeller commented

It's easy enough - and quite appropriate - to exclude immutable objects in the updateAccessedAttributes algorithm, since we really only mean to check for identical attribute values whose state has been changed internally... and those well-known immutable classes don't ever fall into that category.

That said, a servlet container's own clustered HttpSession implementation could also be smart enough to check for that case itself: comparing the existing attribute value to the new one, and skipping the update if it's the same reference to an instance of an immutable class. I suppose that no existing servlet container does this though? Have you checked this against any specific containers / servers?

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I've added this to 4.1 (master) now, explicitly skipping the re-set step for String, Character, Boolean and any Number values. It shouldn't have any side effects but since it's not a showstopper, I'd like to run it through the 4.1 release candidate phase first (i.e. and not backport it to 4.0.5).

Juergen

[spring-projects-issues]

Dongqing Hu commented

Number is not immutable, e.g. AtomicInteger, AtomicLong.

Integer and Long are final classes, which are safe. And I directly check class equality.

I didn't use server's own cluster implementation. But checking immutability is based on checking modifications (which Spring had already). I think Tomcat doesn't work in this way. So I guess servlet containers do not have this.

[spring-projects-issues]

Juergen Hoeller commented

Good point! Revised to support standard number types only now, as determined by a new constant on NumberUtils.

Juergen