db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.fhg.de>
Subject Re: Layer Design [was Release OJB 1.0.01]
Date Sun, 01 Aug 2004 16:48:36 GMT
Brian McCallister wrote:

> I am of the opinion that too much functionality has probably been pushed 
> into the PB right now in order to compensate for the lack of exposed 
> functionality in the ODMG, and the immaturity of the OTM.
> 
> I'd like to see a PB style API with the transaction and dirtying 
> capabilities. Along those lines I have been doing a lot of work on a 
> library to handle the object state tracking and manipulation, which I 
> wanted to get fully hooked up with PB callbacks before bringing it up as 
> a serious option.
> 
> Too late =)
> 
> Short form of what I have right now is a library to which persistent 
> instances can be attached, which tracks the CLEAN/NEW/DELETED/DIRTY 
> states of objects and collections, provides callbacks on state changes, 
> and is capable of rolling back purely from the object model. There are 
> no dependencies other than JDK 1.2 or 1.3 (should be 1.2 but I haven't 
> actually tested it there). There is also, to a lesser degree, graph 
> dependency information available in terms of who references a given 
> object, etc. This information, combined with the pk/fk knoweldge 
> directly, or a topological sort knowing how we map fk's in general, 
> would allow for statement re-ordering. It also handles various JDO2 
> things like attach/detach in a compliant manner.
> 
> My thinking in terms of design is that one or two layers sit under this. 
> The "one" would be the PB directly. The "two" would be an 
> isolation-level handling layer, then the PB.
> 
> I *think* the internal design of this stuff is easier to follow than the 
> OTM internals right now, mostly as it doesn't attempt to do as much. 
> Isolation is a separate concern from state tracking, in my thinking. 
> With this, the PB would need to provide the direct ability to do CRUD, 
> to manipulate the contents of collections, and finally, to allow 
> manipulation of M:N implementors somewhat. All of which exists =)
> 
> In terms of using it, the integration could be done 100% via callback 
> registration on the existing PB. The o.a.o.broker.dirty.* stuff is 
> basically a proof-of-concept on the callback hooks from the OJB side 
> (registering instances, etc). Instead of using the tightly-coupled-to-PB 
> stuff in said package now, the callbacks would register to a tx/unit in 
> this library, passing through the isolation layer if we want that, and 
> hopefully we could then go ahead and expose the PB with full OTM/ODMG 
> style abilities.
> 
> The default for state tracking right now is reflective comparison, 
> though it is abstracted out such that using a bytecode enhancement 
> strategy would work very well (was designed very carefully to allow 
> this) and would increase performance a lot -- no graph traversal with 
> fieldwise comparisons needed at commit time.
> 
> Anyway, I don't have anywhere good to put this code right now, and 
> didn't want to add it to our repository until it was decided if we even 
> wanted to use it. Source xref's are up at 
> http://kasparov.skife.org/grafolia/xref/index.html under my personal 
> namespace and listed as copyright myself, but is has never been released 
> and is intended for checkin to OJB =)

How does that work together with caches, esp. the two-level cache that 
Armin works on ?

> Should I go ahead and add this, or drop it?

I'm not entirely sure how much of that is visible to the outside (e.g. 
the OJB users) anyway, and if it usable by PB, ODMG and JDO, then I'm 
all for adding it to OJB.

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message