Hi Andrew,
Clute, Andrew wrote:
I am sure this conversation has been had before, but with the
introduction of the new ProxyFactory, I think it is worth revisiting.
The question is: what is the best way to handle the serialization of
Proxies (both reference and collections).
The current pattern was to let the JDK Proxy serialize as normal, with a
reference to a PBKey. After being restored and interrogated, the Proxy
would reconnect to a PersistenceBroker (in whatever VM it was in) and
materialize the object.
Is this the pattern that should continue forward? If so, then a change
will need to be made to allow the IndirectionHandler to maintain a
non-transient reference to a PCKey (is this ok?).
think this is ok.
If a user try to materialize a proxy object on a JVM without access to OJB what will happen? Can we provide a useful error message when using the JDK proxy classes (when cglib isn't in client classpath an exception will be thrown when accessing the proxy object - or)?
Other potential options are to always null out references and collections, or to fully populate references and collections. Both make the serialized object completely detached, and non-dependant on having the second VM be able to work with OJB.
The second option can be critical when the user try to store the "nullified" object without using PB.retrieveAllReferences(...) before (if the IndirectionHandler is null out how could a user materialize the real object? PB.retrieveAllReferences only works for references!), because OJB will "think" that the detached objects be deleted.
But if the client is "read-only" and only interested in the main object this option could be helpful.
The third option is safe but can affect performance when always the whole object graph is materialized, but for clients without a running OJB app this will be currently the only option (beside not using proxy).
This could also be configurable....there could be Strategies for all 3,
and the user could choose which is best for their use case.
If the "configurable way" isn't too complex this will be the most flexible solution, otherwise I would prefer the first solution with serialized PCKey.
regards, Armin
Thoughts?
-Andrew
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
