I've developed a JSF application using Tomcat 6. Target state is Websphere 7.
I've made what I assumed sensible use of backing beans. Application scope for caching static data from RDBMS, session for typical "shopping cart" info which includes session related information such as a customer id, account details, and request beans for single request type stuff.
It was great fun, a great challenge, lots of hurdles to overcome, but it's time to make it really work.
Enter a clustered Websphere arena, the target state. Now, I've been curious all along how these different types of backing beans are to be persistent should the environment be multi-servered, instead of a single server as in my Tomcat development. Throughout development, whenever I viewed source, there was obviously lots of embedded JSF related stuff, which I assumed was some type of session object serialization. I've had the STATE_SAVING_METHOD set to client, just because that was the default. (A little reading, and it seems that SSM configuration option has to do with the view, and I'm assuming that might suggest it has nothing to do with any backing beans?)
It was obvious as soon as I rolled into Websphere I've got big problems with my backing bean states. I've not ruled out something stupid on my part. The first session scoped backing bean is created for the application. The next page has a mixture of a request scope bean, and some session scoped bean information generated in the first page. It invokes an action on the request scoped bean, which tries to pull in data from the session scoped bean, and the session scoped bean cannot be found. According to logs, the original page was renderred in WAS "WebContainer 0", but the second is being handled in "WebContainer1". So, naturally, I'm thinking the session bean is available in WC0, but is unavailable in WC1.
Can anyone explain the obvious thing I'm missing here, and hopefully tell me I'm not totally screwed? Oh yea, a solution would be good too.