Re: [OJB-developers] access paths and "object graph sectioning"

[Thomas M. <tho...@ho...>]

Hi Mike,

Mike Hogan wrote:

  > Hi,
  >
  > I have just posted this to jdocentral.  Please forgive the cross 
posting.
  >
  > I got quite excited about JDO because I figured it would allow me 
persist
  > data on the serverside without the muckiness of Entity Beans.  I also
figure
  > JDO objects could act as my value objects - that I could return them
to the
  > presentation layer from my session beans.  I see that there are 
arguments
  > for and against that idea on this site and others.  But lets leave that
  > argument aside and assume I want to return my JDO instances as value
objects
  > from session beans.
  >
  > The problem is of course that if I return the head of a graph of 
objects,
  > the whole graph will get serialized back to the client.  The only way
around
  > that right now that I can see if judicious placement of nulls to cut the
  > graph.


OJB provides several concepts to deal with such situations:
- you can configure OJB to use proxy objects instead of "real" object
references. This will cut your graph *and* allow you to navigate to the
"real" object if necessary. OJB proxies are serializable and can be
excuted even in remote JVMs !

- you can configure OJB not to retrieve Object references. It will
simply place null values in the reference objects.
This will cut your graph, but OJB can't follow the references
automatically. So for *most* situations using proxies should be
asolutely sufficient.


  >
  > But it seems to me JDO is well positioned to do this for me.  Lets 
assume
  > the JDO runtime loads data for an object only when the reference to that
  > object is navigated (the root object is a special case).  This will
allow me
  > surf my object graph to my hearts content in my session bean, loading
data
  > as I go.


Very easy to implement with OJB.


  > When I have done the surfing I want to do, I currently have to insert
nulls
  > to cut a section out of the object graph so I can serialize it back
to the
  > client.  Would it not be possible to tell the persistence manager NOT to
  > load data for any further references that are navigated, but to
return null
  > instead.  Then I can simply do persistenceManager.cut(), and serialize a
  > section of the graph back to the client - java serialization will be
bound
  > to the area of the graph I surfed.
  >
  > Now, this might very well remove the opportunity to do preloading of 
data
  > for performance reasons.  But it would be really cool if these access
paths
  > were implemented in 2.0.  Then I could load an object from the db and
tell
  > the PM what the expected access path is, with one access path per use
case.
  > This will allow me load data in a performant way while still
sectioning the
  > graph.


OJB has a Metaobject protocol to manipulate the behaviour of object
references etc. at runtime.
To implement you idea with OJB is quite straightforward.


  >
  > One extra nice extension would be a means to indicate what access paths
  > follow a given access path.  For example, if I am executing the
"login" use
  > case, I would tell the PM to work with the "login" access path.  But
I could
  > also inform it (at deployment time probably) that after the "login" use
  > case, the "order item" use case or the "logout" use case can follow.
   To the
  > JDO runtime, this will mean the "order item" or the "logout" access path
  > will follow, and it can preload both if it chooses, or, depending on
their
  > relative frequence, load one of them.


All this is possible with OJB already today. Don't wait for 2.0 !

cheers,

Thomas


  > Cheers,
  > Mike
  >
  >
  >
  > _______________________________________________________________
  >
  > Don't miss the 2002 Sprint PCS Application Developer's Conference
  > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
  >
  > _______________________________________________
  > Objectbridge-developers mailing list
  > Obj...@li...
  > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
  >
  >
  >
  >