In an example (see attachment), I'm using a Serializable class that implements readObject() and writeObject(). When the class is serialized and stored into a database, writeObject() is called twice instead once.

Based on a JIRA issue 3398 (https://issues.jboss.org/browse/JBPM-3398), I believe that class instance is stored twice: once in SessionInfo and once in ProcessInstanceInfo.
And class is defined as a process instance parameter, so I think it should be stored only once in ProcessInstanceInfo.

As for double serialization, I think the object should be stored only once (and in the right context) in the db because of the following:

• correctness: if object is stored twice, you risk getting a discrepancy between same object instances, because the framework might update one instance, and not the other
• correct scope: I think process instance variables should be stored in the right context. It does not make sense that process instance variables are stored in session scope. If session needs that information (as I've seen that RuleFlowProcessInstance class does), you should have a means to gather that information from the underlying process instance. And, as one session might have up to N process instances (because one session can have many process instances), you end up with huge byte array in a SESSIONINFO table, where each process instance is serialized (with its process variables)
• database storage consumption (taking into consideration that one process may have a lot of process variables)
• placeholder resolver strategy use: session serialization does not make use of the (placeholder) resolver strategy defined in the environment, and process variables are always serialized in a SESSIONINFO.