Win a copy of Microservices Testing (Live Project) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Session backing beans / STATE_SAVING_METHOD / WAS7

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks

reply
    Bookmark Topic Watch Topic
  • New Topic