That is kind of what I assumed. It makes using proxies somewhat worthless in an EJB environment, at least in my opinion. Proxies to me seemed to be a great way to do lazy instantiation, and keep the client ignorant of persistence mechanisms.
So, if you have to materialize the entire graph before serialization, then you really don't gain anything.
Instead of materializing the whole graph, one could also set these objects to null or some instantiation of a class known to the client. Then the client doesn't need to know about OJB at least. But it does mean that the client can't be "ignorant". My graphs can be large enough to overwhelm the client, so I find that using proxies, in spite of these drawbacks, is crucial. Proxies will be also unavoidable when the complexity of the querying I need to do to keep up with reporting needs become more demanding. And I'd rather not consider for the moment multiple repository_user settings (i.e. defining classes in be proxied in one context and non-proxied in another)...
Phil
Thanks for the response!
-----Original Message-----
From: Phil Warrick [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 11:01 AM
To: OJB Users List
Subject: Re: Best practice for using ODMG with EJB? (Cache also)
Hi Andrew,
All that leads me to another question that I don't seem to find an answer
to: if a remote EJB passes off an OJB dataobject, I would assume you
cannot
use any proxies because it would not be able to walk back across the wire, correct? I am currently not making use of any proxies because of that assumption. Seems to me that proxies don't fit well at all with EJB's.
You can use proxies with EJB across the wire (I do, in ODMG mode), but the downside is that the client must never try to materialize them and the client needs to be OJB-aware. Before dereferencing a proxied object on the client side, care must be taken to ensure that they have been materialized on the server before serialization. There is a tradeoff here in controlling object-graph size with proxies on the one hand, and transparency of access to persistent classes--regardless of whether the JVM is local or remote--on the other.
Removing the need for the client to be OJB-aware could be resolved at either the OJB level or in your application by altering serialization code (writeObject()/readObject() methods I believe) for your persistent classes, to replace any proxies with something else. But in this scenario the client still needs to be concerned with delegating to the server any materialization of associated objects that must be accessed.
There has been some discussion from time to time on improving this.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
