Please consider the following scenario:
We are working on a JavaEE project for which the scalability starts to become an issue. Up until now, we were able to scale up but this is no longer an option. Therefore we need to consider scaling out and preparing the App for a clustered environment.
Our main concern right now is serializing the user sessions.
Sadly, we did not consider from the beginning the issue and we are encountering the following excetion:
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.catalina.session.StandardSessionFacade
I did some research and this exception is thrown because there are objects stored on the session which does not implement the Serializable interface. Considering that all over the app there are quite a few custom objects which are stored on the session without implementing this interface, it would require a lot of tedious work and dedication to fix all these classes declaration.
We will fix all this declarations but the main concern is that, in the future, there may be a developer which will add a non Serializable object on the session and break the session serialization & replication over multiple nodes.
As a quick overview of the project, we are developing using a home grown framework based on Struts 1 with the Servlet 3.0 API. This means that at this point, we are using the standard session.getAttribute() and session.setAttribute() to work with the session and the session handling is scattered all over the code base.
Besides updating the classes of the objects stored on session and making sure that they implement the Serializable interface, what other measures of precaution should we take in order to ensure a reliable Session replication capability on the Application layer?
I know it is a little bit late to consider this but what would be the best practice in this case? Furthermore, are there any other issues we should consider regarding this transition?
Thank you in advance!
1
If you are considering only a scaled out, clustered environment, with replicated Sessions, then you don’t have a workaround. All of your objects must be Serializable.
But if your application and Java EE architecture allows you to do a scaled out “clustered” environment without replicated Sessions, then you are fine. The only thing you will lose here is the ability to keep a user logged in and redirected to another server when the one he was interacting with was shutdown for some reason. This user may be redirected to another server, but he/she will have to sign in again and if your application is not smart enough, he/she will have to start whatever they were doing, all over again.
If you really cannot make sure your objects are Serializable, consider a load balance for “unclustered” Java EE web containers (EJBs may continue to be clustered and may give you greater scalability) with sticky-session and non-replicated HttpSession.