Bug 58284

Customer reported an issue with non-serializable objects when using our DynamoDB Session manager (https://github.com/aws/aws-dynamodb-session-tomcat/issues/30). After digging into the code it looks like StandardSession is attempting to do several things when giving non-serializable attributes. For top level objects that don't implement serializable it silently removes it. That code is working fine although I am a little wary that it doesn't fail as this could hide bugs in the users code and make it difficult for them to determine why a certain attribute isn't being persisted to the backing store. After that StandardSession attempts to write the remaining attributes to the ObjectOutputStream. If a serialization exception is encountered here (i.e. some object in the object graph does not implement Serializable) then the exception is caught and a special indicator NOT_SERIALIZED is written to the object stream and a warning is logged. Now internally ObjectOutputStream is handling the same exception and writing it's own special marker, TC_EXCEPTION, and the serialized exception object to the stream. This is written before StandardSession has a chance to write NOT_SERIALIZED. In StandardSession.readObject there is logic to skip deserializing any objects that have been written to the stream as NOT_SERIALIZED. This code can never actually be executed though as ObjectInputStream is checking if there are any occurences of TC_EXCEPTION and will deserialize the exception object, wrap it in a WriteAbortedException and throw it out. This causes a session with non-serializable objects in the attributes to be written "successfully" but causes an exception to be thrown when attempting to read that same session.

I understand modifying StandardSession to now throw exceptions when non-serializable objects are encountered could be considered a breaking change so I propose adding some kind of overload or configuration to enable this behavior for users that want to opt in. Failing fast when non-serializable attributes are detected seems like the right way to go as this should be fixed in the customers code. I'm willing to submit a patch for this although I wanted to open the issue first to make sure you concur with my assessment and coding up a patch is worth my time.