0

As I'm working on a vaadin project, I need sticky sessions for session replication. Otherwise, it won't work. I'm using JDBC to store the session. But since it's not sticky yet, the website keeps refreshing when starting the app. I know it has something to do with the load balancer. But since I'm a total beginner I have no idea how to access it and set custom configurations.

This is my properties file

server.port=${PORT:8080}
logging.level.org.atmosphere = warn
spring.mustache.check-template-location = false
spring.session.jdbc.initialize-schema= embedded
spring.jpa.hibernate.ddl-auto=update
spring.datasource.driverClassName=org.h2.Driver
spring.session.jdbc.table-name=SPRING_SESSION
spring.h2.console.path=/h2
spring.h2.console.enabled=true
spring.session.store-type=jdbc
spring.datasource.url=jdbc:h2:~/sessions
spring.datasource.username=xx
spring.datasource.password=xx
vaadin.launch-browser=true

And here are my dependencies

<dependencies>
        <dependency>
            <groupId>org.springframework.session</groupId>
            <artifactId>spring-session-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.session</groupId>
            <artifactId>spring-session-core</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>com.vaadin</groupId>
            <artifactId>vaadin-spring-boot-starter</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-validation</artifactId>
        </dependency>
    </dependencies>
ladybug
  • 45
  • 1
  • 6
  • 2
    If you are using Spring Session JDBC you shouldnt need sticky sessions. your database is emptied upon starting due to `spring.session.jdbc.initialize-schema: always` which basically drops and recreates the database on application start. Trying to apply sticky sessions won't change that (nor should be needed and would defeat the purpose of Spring Session). – M. Deinum Dec 15 '22 at 10:40
  • @M.Deinum Okay but if I change it to embedded? I wrote always because I saw that in another StackOverFlow post, since the h2 database threw errors. But now it also works with embedded. Is JDBC in general not the good choice? – ladybug Dec 15 '22 at 10:46
  • 1
    When using H2 as an in-memory database it is also pretty useless for production as after each restart your data is gone, nice for testing/dev not your live system. If you want to use JDBC, which is perfectly valid, use a proper database to make it persistent. – M. Deinum Dec 15 '22 at 10:50
  • 1
    I feel that "sticky sessions" and "for session replication" are somewhat of a contradiction. Typically I see them configured on Appserver- (e.g. Tomcat) and Loadbalancer- level rather than on application level. _Sticky_ session means that a session will always be directed to the same backend server (by the load balancer), so technically it wouldn't need to be persisted at all (until the backend server fails unplanned). – Olaf Kock Dec 15 '22 at 11:03
  • Thank you for the clue of configuring them on Appserver level @Olaf Kock. And for explaining the concept of sticky sessions so easily. I think you're leading me towards the right path. This is all quite new to me and no one at work can really help me at all. Still a student, haha – ladybug Dec 15 '22 at 11:15
  • If you are using Sticky session it beats the purpose of Spring Session JDBC which wouldn't require sticky sessions. The problem with your setup is that if you have multiple servers they aren't using a shared database for session storage (which they should), that way you wou;dn't need sticky session. Sticky sessions are considered a bad practice (afaik) as that ties your session to a single instance, now if that dies the app stops working. – M. Deinum Dec 15 '22 at 12:24

0 Answers0