Good point to raise Paris. Here are the practices I (and others) have been using, they work well
1) Do not assume serialization, that is true. If you need to make sure that the instance of the data is not shared after the message, send a manually serialized version. The "InstantiationUtil" has methods to serialize/deserialize into/from byte arrays. 2) If the data involves user-defined classes, always serialize manually, because the derserialization in the akka stack will not use the required user-code classloader. Have a look at the class "SerializedValue", which eagerly serializes and lazily deserialized (with a given class loader) to overcome these situations. 3) I totally agree to not make any assumptions on the behavior of transient fields. Stephan On Tue, Apr 21, 2015 at 1:41 PM, Paris Carbone <par...@kth.se> wrote: > Hello everyone, > > > Many of you are already aware of this but it is good to make it clear in > the mailist. We bumped into this "special" case with Akka several times > already and it is important to know where transparency actually breaks. > > > In short, Akka serialises only messages that get transferred over the wire > or across JVMs [1]. Thus, we should not rely on messages getting serialised > for anything we want to transfer using Akka. To overcome this we should > either: > > > 1) Do a deep copy of everything passed via Akka messaging > > 2) Apply serialisation manually before sending messages and transfer only > pre-serialized data. > > 3) Never rely on transient fields > > > cheers > > Paris > > > [1] http://doc.akka.io/docs/akka/snapshot/general/remoting.html > >
