Spring MVC，@ SessionAttribute和可伸缩性

Question

We are building a Spring-MVC web application for 80 000 users.

I see a lot of controllers in the petclinic example using : @SessionAttribute annotation and SessionStatus status ... status.setComplete() to store and remove the beans from the HTTP Session. Very useful indeed.

Is it the best way to go if you plan to build an application for 80 000 users ? Could you still use session load balancing and session failover if you plan to store all your form data like this ?

Answer 1

It will probably not meet your needs, no. There are two principle problems with the built in implementation:

1. It doesn't really support tabbed browsing. If a user loads the same screen in multiple browser tabs, the two tabs accessing one controller are going to clobber each other's session attribute data.

2. If users don't follow your "planned" navigation path that setComplete() call will get missed and the object hang around indefinitely until the session expires and is cleaned up.

Number 1 may or may not be a concern depending on how your app is designed and what it does. (some things, eg, Banks, deliberately thwart mult-tabbed usage anyway) But most users I think would expect to be able to edit User A's profile in one tab and User B's profile in another tab and not have submitting one form break the other screen.

Number 2 you could work around by always submitting a screen into its own controller then redirecting after cleanup, but that's a lot of work if you aren't already building that way.

The good news is org.springframework.web.bind.support.SessionAttributeStore is a recognized extension point! You can provide any implementation of that you like and inject it in your dispatcher servlet. You don't even need to use the Web Session to store information if you want to avoid bloating it up with business objects. You could put that actual storage in a backend terracotta cluster for example, and not worry about it being compatible with your clustering strategy.

--

And then there's always option Gamma if you really need true scalability: rework it into a RESTful strategy that doesn't rely serverside state in the first place :)