J2EE Bad Practices: Non-serializable Object Stored in Session

Modern Java applications often run across multiple servers (JVMs) for better performance and uptime. To present a seamless experience, the application server needs to copy a user's session data between these servers, especially if one fails. This replication process requires every object stored in the `HttpSession` to be serializable—that is, convertible into a byte stream for transfer. If a non-serializable object is placed in the session, this failover mechanism breaks, potentially causing errors during server scaling or outages. For developers, this means any class whose instance is added to the session via `setAttribute()` must implement the `java.io.Serializable` interface. Common culprits include custom helper classes, third-party library objects, or database connections that weren't designed for serialization. Failing to ensure this prevents session replication, undermining the reliability benefits of a clustered deployment and leading to inconsistent user experiences during infrastructure changes.