Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C536E2.9FB1C921"
Subject: Serialization of Proxies revisited
Date: Fri, 1 Apr 2005 12:45:41 -0500
Message-ID: <316E5B943771D311BAC500805FD7A07804127069@MAIL.osn.state.oh.us>
Thread-Topic: Serialization of Proxies revisited
Thread-Index: AcU24p9yQRrk8LgzSIq+GMO1QlEIxw==
From: "Clute, Andrew" <Andrew.Clute@osn.state.oh.us>
To: "OJB Developers List" <ojb-dev@db.apache.org>

------_=_NextPart_001_01C536E2.9FB1C921
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am sure this conversation has been had before, but with the
introduction of the new ProxyFactory, I think it is worth revisiting.
=20
The question is: what is the best way to handle the serialization of
Proxies (both reference and collections).
=20
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.
=20
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?).
=20
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.
=20
This could also be configurable....there could be Strategies for all 3,
and the user could choose which is best for their use case.
=20
Thoughts?
=20
-Andrew
=20
=20
=20
=20

------_=_NextPart_001_01C536E2.9FB1C921--