Java serialization is an anti-pattern now, most TransactionManagers rely on DataSource which is not serializable, and neither define serialVersionUID nor readObject() will cause potential exception, I think is time to remove java.io.Serializable from TransactionInterceptor and *TransactionManager. Any one can explain what is the purpose to make them serializable?
This is by design for the time being, with transaction managers potentially reconnecting themselves to a given runtime environment. The common resource transaction managers cannot do this but JtaTransactionManager is capable of re-retrieving its JNDI resources and being fully active again, potentially even in a different JVM but in particular on deserialization within the same JVM... for example in a clustered session setup or for serialized sessions on shutdown.
Granted, JTA is certainly as out-of-fashion as serialization is today. At some point we might be able to let go of both... but not within our planning horizon yet.