Feature/cluster support with spring session #123
Conversation
… with spring-session-jdbc)
Codecov Report
@@ Coverage Diff @@
## master #123 +/- ##
=========================================
Coverage 15.45% 15.45%
Complexity 473 473
=========================================
Files 438 438
Lines 8740 8740
Branches 832 832
=========================================
Hits 1351 1351
Misses 7304 7304
Partials 85 85
Continue to review full report at Codecov.
|
tesler-core/src/main/java/io/tesler/core/util/session/impl/SessionServiceImpl.java
Outdated
Show resolved
Hide resolved
|
As I know, |
It is seems to work fine. Illustrated it at this moment https://youtu.be/2K2jZy6iGpY?t=121 |
…_CACHE which is not scoped to session. This will give better performance in cluster mode with spring-session-jdbc (<=> no cache, because it stores session data in DB). At the same time for single node mode it will give almost same performance as session scoped cache. Trade off here is average RAM size for USER_CACHE (elements are not deleted from cache when user logs out), but when all users log-in at the same time, then both session scoped and current caches will require same RAM. So max RAM size is the same. In concrete app using tesler and having lots of users one should consider redefining bean @primary @bean(name = USER_CACHE) public Cache sessionCache() {} with some cache provider supporting memory limits and auto cache eviction (hazelcast and so on), so USER_CACHE is kept as separate cache from UI_CACHE in this commit
|
Kudos, SonarCloud Quality Gate passed!
|
Cluster support with spring session added.
Before this MR tesler platform in cluster mode produced error (see 2 node scenario)
After this MR one can choose any spring-session provider (jdbc, redis and so on) and work in cluster mode (see scenario for tesler-doc exmaple application. Includes configuring spring-session-jdbc and working with 2 nodes)