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. 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]
