I read through the Hazelcast docs to see how they do it. They basically require each type to implement Serializable, but it can also implement DataSerializable instead, which provides a more efficient way of serializing by giving direct access to DataOutput and DataInput types. This provides methods to write/read literal types directly instead of converting an entire object into a byte-array. These makes a lot of sense since data classes are typically an aggregation of strings, collections, numbers. These can be handled directly by the toolkit without using byte array serialization.
I think we could keep this in the back of our heads as a possible solution for a future version and detect also on the interface that the data implements that is stored into a toolkit collection. Thoughts? On 26 May 2010, at 08:28, Alex Snaps wrote: > Don't mean to hi-jack this thread, but I wanted to continue on custom > Serialization mechanism to go beyond Java Serialization capabilities, > that we discussed in this meeting: > I didn't like the decorated data structure approach so much, for the > same reasons as Chris mentioned. > Thinking slightly more about it, I'd much rather like some JCE kinda > mechanism, where one could register Serialization mechanism > cluster-wide. When data get serialized it would also be signed so that > the proper strategy to deserialize the stream can be automatically > selected. > Now that raised the question about the default mechanism to use and > possibilities to override it depending on the data structure's > instance or even usage. > So I guess instance-wise, a constructor argument could register the > strategy with the mechanism and with the global registry (unique > identifier). > If there is a requirement for usage-based strategy (different > strategies in the same instance), we could fall back to decorating > e.g. the Map, so that all entries added through that decorated > instance would use another serialization mechanism... Now, would we > need to track (instance- or, for maps, key-based) what strategy to use > overtime? > This all of course doesn't answer the question when this Serialization > is to happen. > Something in that direction could then also probably ease version > transitions on stored Object. > > Just wanted to get this out of my head and shared, even though I think > this is less relevant now, given how I understood the discussion > ended. > Alex -- Geert Bevin Terracotta - http://www.terracotta.org _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
