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

[<tr...@th...>]

I think you're right for the most part and I hope that more things will get developed as needed such as the StateManager.  

I just really want to be able to use JDO right now and at the same time get all the benefits of using OJB.  If you or others are thinking hte same way, then everyone who is interested should help out with this project so we can get a real implementation going.  It sounds like you know the JDO spec like the back of your hand and any input you have on implementing it would be greatly appreciated.

cheers

Travis

---- Original Message ----
From: Sebastian Kanthak <seb...@mu...>
Sent: 2002-05-17
To: obj...@so...
Subject: Re: Re: Re: [Objectbridge-jdo-dev] JDO implementation

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

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: ban...@so...
_______________________________________________
Objectbridge-jdo-dev mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev