Add optional Hazelcast session serializer

[enozcan]

Related: #1131

Provides custom serializer optimized for Hazelcast rather than native Java serialization.

Backward Compatibility

This is an optional serializer. If Hazelcast instances are not explicitly configured to use, the serialization mechanism will remain unchanged. However, it's not possible to use this serializer for an existing session store serialized without this.

Requirements to Use

In embedded mode, it can be configured directly just before a member starts. In client mode, the serializer - and hence the MapSession, need to be present on member's classpath and configured. Both Hazelcast client and member must use the same serialization mechanism for consistency.

About Hazelcast's Portable Serialization

Portable (not used in this PR) is another way to serialize the objects in Hazelcast way. It also fits well with the indexed repository. Because in the current scenario when a query is made to fetch sessions by the principal, the objects on the distributed map are deserialized to extract the value, then serialized and transferred to the caller side, and then deserialized again. Portable serialization, on the other hand, allows map values to be queried without deserializing the whole value but only the necessary one - in this case, PRINCIPAL_NAME_ATTRIBUTE.

However, Portable requires a serialization interface to be implemented for the objects to be stored on the map. In that case - as MapSession is final, a wrapper for sessions could be good to go. But this would require some changes in HazelcastIndexedSessionRepository and more importantly, would break the backward compatibility for the sessions serialized in the old fashion. So I think it's better for now to keep this serialization logic optional - maybe until 2.4.0.

More on Portable

Also, with the next versions of Hazelcast, it will be possible to run entry processors (in spring-session-hazelcast, sessions are updated via entry processors on the member side, without the need for fetching and then putting the value on the caller side) without including a dependency on members. When this is the case, it will prevent users to be required to adding their classes when using client/server topology. The current version uses user code deployment for this, which is actually not the best way of. (related: #1584)

[eleftherias]

@enozcan Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@enozcan Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@enozcan Thank you for signing the Contributor License Agreement!

[eleftherias]

Thanks for the PR @enozcan!
I have left one small comment inline and then this can be merged.

[enozcan]

Thanks for your review @eleftherias.

As I explained, the serialization issue for Hazelcast sessions could have been even more efficient via some breaking changes. But my main concern was to conform backward compatibility and hence made the serializer in this PR optional. However, now that I see you added Hazelcast 4 support as another module, I wonder if we can perform some changes in that Hazelcast 4 module which are not backward compatible at all - considering this is a newly introduced module. The only outcome that makes me worried is having two different types of modules for Hazelcast 3 and 4 might be somehow complicated to users.

WDYT? I also wonder what the expected release date of 2.4.0 is.

[eleftherias]

@enozcan 2.4.0 is scheduled for October 28, 2020.

Thank you for the suggestion.
For now, I would like to keep the Hazelcast 4 module as minimal as possible.
It is meant to make Hazelcast 4 useable, but any enhancements are better suited for the next major release (3.0).

3.0 isn't scheduled yet, but I will update https://github.com/spring-projects/spring-session/milestones when we have an estimated date.