ReactiveHazelcastSessionRepository #2222
Open
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
I was able to convert the
Hazelcast4IndexedSessionRepository
into aReactiveSessionRepository
using exclusivelyIMap
’s*Async
methods, with only small limitations, mostly the same as for Redis and Mongo:FindByIndexNameSessionRepository
(see Add ReactiveFindByIndexNameSessionRepository #914), so those features cannot be supported (at least through an interface implementation)FlushMode.IMMEDIATE
cannot be supported since theSession
interface is not reactive (I assume it is the reason why the Redis and Mongo implementations do not support it)IMap.delete()
does not have an async equivalent, soIMap.removeAsync()
has to be used – see hazelcast#10702removeAsync()
could be ignored?I still don’t know why hazelcast/hazelcast#3622 was supposed to be needed for #831 so I would be glad to hear if this approach could cause any issue.
I think some refactoring should still be done to avoid code duplication, in particular on the event management, but possibly also in the usage of
HazelcastSessionUpdateEntryProcessor
.The only code change I did in existing code is adding
equals()
andhashCode()
(for Checkstyle) toHazelcastSessionUpdateEntryProcessor
, as it makes it much easier to declare mocks for unit tests.I am creating this PR against 2.6 because it is the version we are using, but it can as easily be merged in 2.7 since there are no differences in the Hazelcast 4 module between the two (just need to change the
@since
).I didn’t check for 3.0 yet since I don’t have a real application to test it – I am aware merging this will require some manual operations due to the reorganization of the Hazelcast module but I hope this can be tackled later.
p.s.: I was a bit confused by the formatting rules.
.editorconfig
indicates LF, but gradle build seems to somehow expect CRLF.Moreover it also uses
latin1
for Java and XML files instead of UTF8, andcontinuation_indent_size
does not seem to be a valid setting.Closes #831