[concurrency-interest] Concurrent Serialization Pattern

David Holmes dcholmes at optusnet.com.au
Sat Sep 16 00:48:05 EDT 2006


Kevin,

> Here's a solution using readResolve() that I tested successfully.

I've somewhat lost the original problem that was being solved :) The issue
with final fields and serialization is that if you need to perform custom
deserialization of the final field then you can't do it directly. You then
have two alternatives that I am aware of:

1. You use custom deserialization, reflection and setAccessible(true) to set
the final field to the desired value; or
2. You use readresolve to replace the deserialized object with an equivalent
one that you can construct with all the right final field values

The issue I believe you were trying to address in your serialization code
was the possibility of unsafe-publication of the deserialized object. As you
indicated originally if the deserialization process uses the same lock that
is used to access the object's state then there can be no races. Hence
readObject deserializes while holding the writeLock. writeObject also uses
the readLock to ensure a consistent snapshot of the object's state (though
the idea that you would serialize an object while it is being actively
mutated is a little worrying :) ). So your pattern made the object immune to
unsafe-publication - though as we have discussed in the context of
constructors, generally it is not worth the effort to achieve this level of
thread safety - just ensure you do publish safely.

Now somewhere a long the way you decided that your final Lock field needed
to be transient. That is the part I don't understand as
ReentrantReadWriteLock is Serializable.

Cheers,
David Holmes



More information about the Concurrency-interest mailing list