Re: Re: Re: [Objectbridge-jdo-dev] JDO implementation

[Sebastian K. <seb...@mu...>]

Hi Travis,

On Friday 17 May 2002 03:03, you wrote:
> I made a tutorial3a package that has the Product that does NOT implement
> PersistenceCapable.  Modified build.xml to enhance Product after
> compilation.
>
> And it all works just fine.  Nothing broken.

well. That's because no state manager has been set and all field accesses are 
performed directly.

However, try the isXXX methods from javax.jdo.JDOHelper. For example 
JDOHelper.isPersistent(...) will always delegate to the state manager. If no 
state manager is present (as in your case), this method will always return 
"false", even if the persistence capable instance is persistent. Same for 
isDirty(...) and so on.

So you have to put in a state manager. If you do this, however, most field 
accesses (depends on jdoFlags and jdoFieldFlags) are delegated to the state 
manager.

I think another problem occurs with "lazy-materialization". Suppose you have 
a very large graph of objects. When you load one object via some kind of 
query, you probably don't want all objects to be loaded at once, but to load 
them transparently on-demand, when they are accessed. I'm no ojb expert here, 
but I think, ojb supports this by creating "stub"-objects via the jdk1.3 
proxy feature. When these stubs are accessed the first time, they load the 
"real" object and pass all calls to it in the future. OJB-developers, correct 
me, I'm a wrong here.

While this solutions works and is a nice application of the proxy feature, it 
has several drawbacks in my opinion. The most important is, that it does only 
work with interfaces (correct?). Others are use of a jdk1.3 feature and 
additional unnecessary objects (the stubs) that add another method call.

JDO has the possibility for another solution because of its use of an 
enhancer. Because field accesses are delegated to the state manager (which 
resembles the proxy object a bit), he can decide, when to load objects from 
the database.

Don't get me wrong. I think, that ojb can be used very well for a jdo 
implementation, but as jdo has a slightly different approach, it can only be 
used as a "backend" behind a jdo-layer, that is responsible for the 
communication database <-> state manager. The communication with the 
persistent capable objects is the responsibility of the jdo layer and has yet 
to be developed.

ciao Sebastian

-- 
Sebastian Kanthak    |    seb...@mu...