JSF in clustered environment,

[Bimal Patel]

Hi,

We have IBM WebSphere Portal Server running in a clustered environment with session replication on. Lets name it as Env-A. Now, the developers used JSF components in their session scoped managed beans. These components are mostly binding components for HtmlDataTableEx (IBM-JSF impl of HtmlDataTable). Lets call such managed bean as MB-1. When the code is deployed on Env-A, and when user logs in; browsing to a page which is linked to MB-1, it throws java.io.NotSerializableException, at the time when it tries to replicate the same session onto other server on the cluster, as HtmlDataTableEx is not serialized.

I found one technote to deal with this. I've used solution formula as directed, but even that is not effective, as I still get the same exception. As IBM's implementation uses such base impl, the problem will be resolved if I am able to find a base JSF imp. with serialized base components. Any suggestion/help would be highly appreciated? Have I explained necessarily?

[Cameron Wallace McKenzie]

Wouldn't a better solution be for the developers not to put non-serializable objects into the Session?

-Cameron McKenzie

[Tim Holloway]

You are playing with fire. There's absolutely nothing I know of in the J2EE spec that guarantees the integrity of nonserializable session data even in a non-clustered environment. If the appserver should decide that the system is loaded, it could potentially start swapping sessions out to long-term storage, and that's only going to work if they can be serialized. So everything in an HttpSession needs to either be serializable or at least capable of accurately reconstructing itself on demand.

You should never attempt to store database connections, network connections or other such trinkets in a session. That's playing with fire in the middle of a petrol refinery.

[Bimal Patel]

To Cameron --> Well, we've reached to a point where a lot of effort has to be made for such code change. The problem is, nobody had a clear picture of the environment. This was realized when we've started deploying code in clustered environment. We're still not sure that whether the production environment will have session replication on or not. But we don't want to take any chances and want to do whatever is necessary before reaching to that point.

To Tim --> I completely agree with you. Non-serialized classes available in any library must not be used in session, if the deployment env. is clustered. As I mentioned earlier, we only have HtmlDataTableEx objects referenced by UIData, inside managed bean. Developers are using this as it is easier to manage a data table when it is bound with an object in the managed bean.

HtmlDataTableEx is ultimately extending UIComponent available in base JSF impl. and according to this technote, the base JSF impl. which has serialized components would be considered once that context param is set to true. Make sense but doesn't work in my case. I wanted to know if someone has already tried this and got the expected result. If there is no such solution available, then there is only one way left, the hard way!

[Tim Holloway]

Apparently this option is not available in older JSF implementations. I've temporarily lost track of where Sun lists these options, so I don't know at what level it kicks in, but probably JSF 1.2.

WebSphere will only honor the option if you have a certain minimum version of the WAS server installed, as indicated by the APARs quoted.

You're more or less stuck with the server's limitations on the core JSF unless you do like JBoss and explicitly pull in an external JSF core instead of using the server-provided one. And I can't really recommend that as a long-term solution, so if you've got a cleaner alternative, take it.

I try to avoid using the JSF component classes directly. For one thing, the "ideal" JSF backing bean shouldn't require any package that begins with javax.faces. (but try that if you have data models!). It reduces portability and testability. For another, I think that their use is overdone - possibly because JSF mutated a lot in its early days and the cleaner, more portable facilities provided by EL value bindings may not have been available when a lot of the original examples were written.

Regardless, the net effect is probably going to be about the same - I just prefer simplicity when I can get it. The actual state-saving issues my require your to have a server upgrade done.