As you probably know, Terracotta doesn't execute the readObject()
method when it hydrates an object onto a cluster node. This is
because it doesn't use Java serialization to move object data around,
so the context of the readObject() call (i.e., the ObjectInputStream
argument) is difficult/impossible to create (I can't think of a way
to do it, anyway...).
Terracotta provides two mechanisms for re-establishing local-JVM
object state: 1) declaring a method to call on object hydration and
2) writing bean shell code to be executed on object hydration.
One way to ameliorate incompatibility issues is to extract any
transient field initialization code that doesn't rely on the
ObjectInputStream out of the readObject() method to another method.
That way, you can configure Terracotta to call that method on object
hydration.
I've spent a little time looking through the Wicket code in trunk,
but I haven't seen many opportunities to take advantage of this
approach. There seems to be a fair amount of custom serialization
code in the write/readObject() methods that write to and read from
the object streams directly. But, I'm not that familiar with the code.
Terracotta is very interested in maintaining compatibility with
Wicket (it's an explicit callout in the requirements for our next
release). I wonder if there's some way we can play nicely together...
--Orion
On 1/29/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
jonathan and i have been brainstorming about removing private
transient
boolean attached=false from our detachable models, and after an
hour here is
what we came up with (see attachment). i know we use some custom
serialization for models, etc so do you guys this is going to
interfere with
that? it almost seems too simple so i am a bit suspicious. if it
works out
it should save a fair bit of memory.
one thing i know it will "break" is terracotta, it will need extra
config
to replicate what we do in readobject()
-igor
