Paul Clapham wrote:For an object to be Serializable, all of its members must also be Serializable. So BanksService must be Serializable; and this rule applies recursively.
Note that the JEE spec requires objects stored in Session scope to be serializable. And, as Paul noted, that includes the objects that they reference. Hmai's link "suggests" to make session objects serializable, but it's common these days for webapp servers to require serializable objects, as John discovered.
There are several reasons for this. One is that if you use clustering, you'll need to be able to pass the entire session from one JVM to another and that's done by serial transfer.
Another is to survive reboots of the JEE container. Tomcat, for example, writes sessions out to a work file with a ".ser" extension so that it can load them back in when it restarts.
You may think that these restrictions are silly/useless in the context of Spring Boot, but Spring Boot gets its web functions from an embedded copy of Tomcat or jetty and Tomcat, at least, actively enforces this constraint.
You might also notice that JDBC Connection is an Interface and that it is not Serializable. Before Tomcat started enforcing the serialization mandate, people were prone to stash Connections in their sessions. That was not only a good way to make a webapp unreliable, it also tied up precious resources. Connections in webapps should be pulled from a Connection pool, used, then returned to the pool (closed) as quickly as possible. And ALWAYS within the same request/response cycle.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
Self destruct mode activated. Instructions for deactivation encoded in this tiny ad.