One thing to be noted from RMI serialization, like any serialization in java is that serialization of the object doesn’t automagically ensure transactional consistency. In other words, if there is some object, which is modified by the background worker thread, and this same object instance is passed via RMI call to client, then it’s possible the client gets corrupted data. Issue can go very likely unnoticed, since such concurrency bug doesn’t manifest itself visible when primitive fields and such are being serialized. With them data is just silently corrupted (meaning it’s not transactionally coherent). However, with collections, it’s possible that concurrent modification errors occur.
One pattern to ensure serialization consistency:
[code lang=”java”]
/**
* Base class for Safely serializable elements. All setter methods
* of the derived class must be also synchronized to ”this” to make
* this pattern to work.
*
* @author kari
*
*/
public abstract class SynchronizedSerializable
implements Serializable
{
private synchronized void writeObject(ObjectOutputStream s)
throws IOException
{
s.defaultWriteObject(),
}
}
[/code]
Now, that is nice and clean solution, right?
WRONG!
There is at least two major defect in the logic: (1) Namely the fact that writeObject() is per class meaning that this same trick must be done in every sub-class containing fields to be serialized, and (2) secondly that all accessor methods must be properly synchronized also. (3) Third problem is that such writeObject() is needed to be implemented at all.
So, how to do this thing then safely, and with maintainable logic?
Answer is naturally simple: Don’t ever try to send over RMI object, which is concurrently modified by other threads. If you still need to do so, use some safe synchronization point in code, and make non-shared clone of the original, and let that go into RMI.