db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Dirty Take 2 (checked in) (feedback please!)
Date Wed, 11 Aug 2004 01:10:32 GMT
Hi Brian,

will have a closer look at your new stuff ASAP.

 > Support for arrays like collections (should be a trivial addition to
 > ManagedTrackerFactory)

OJB supports user defined Collections too via ManageableCollection 
interface. How could this be integrated in Grafolia?


regards,
Armin

Brian McCallister wrote:

> Okay, just did a checkin of take 2 on the dirty broker stuff. This is 
> quite different from the previous (which I will delete from CVS as soon 
> as it is no longer useful as a reference to me =)
> 
> -- 
> 
> Basic design is based heavily on ideas in the OTM, but hopefully 
> benefiting from being the second implementation =) It uses a connection 
> + transaction model like the OTM, except that the Connection part is 
> simply a normal PersistenceBroker, and the Transaction isn't (yet?) 
> exposed to the client, but is controlled solely though the 
> pb.[begin|abort|commit]Transaction() methods.
> 
> Internally the DirtyBrokerFactory (which is designed to be instantiated 
> and ioc/bean configured, rather than statically accessed, even though it 
> uses the PBFactory statics to instantiate its brokers) uses a series of 
> listeners on the PB and on the grafolia Unit to handle events between 
> objects and OJB. The grafolia unit (if we want to expose it to client) 
> can also be used in this regard to do true optimistic transactions 
> (though a little bit more plumbing to make it client friendly will be 
> needed here -- basically hooking in the ODMG optimistic column stuff).
> 
> On commit the grafolia unit walks the graph and applies its reachability 
> function (not yet pluggable in grafolia, but soon =) --  will be in 
> order to properly support proxies) to find newly inserted instances and 
> build a reference analysis of the graph. It then makes the changes and 
> analysis available to OJB, which can order the changes based on looking 
> at the analysis (turns changes into a directed graph based on FK 
> relationships and then sorts them based on the dag traversal).
> 
> -- 
> 
> The org.apache.ojb.dirty.DirtyBrokerTest class in src/test/ shows usages 
> of the stuff. Short form is that it supports, right now: correct 
> dirty-tracking on any PB configuration of auto-*, 
> persistence-by-reachability, statement re-ordering for updates and lazy 
> (reachability based) inserts, and has the hooks necessary (just no API 
> exposed on the PB for it, so nothing to expose the functionality yet) 
> for detach/attach.
> 
> It has some definate rough spots. The statement re-ordering algorithm 
> has the right idea buried in it, but the current impl is definately in 
> the "make it work" phase, not the work right, or work fast. using 
> broker.store(..) on an open transaction can confuse it (not a rough one 
> to fix, just haven't yet).
> 
> A dependency to commons-grafolia (a db-commons-sandbox project, with one 
> author, me) has been added as the graph stuff wasn't dependent on OJB, 
> so I split it off.
> 
> A dependency has been added (temporarily) to commons-graph (a 
> jakarta-commons-sandbox project) to do the topological sort for 
> statement re-ordering. I want to re-implement that part more cleanly.
> 
> Additional Work To Be Done in OJB:
>     Create a grafolia IdentityFactory which wraps OJb id factory
> 
>     Generally clean up the adaptation layer, it is the smelliest hunk of 
> code at the moment.
> 
>     Decide how to expose direct lazy-insert and lazy-delete (executed at 
> commit time)
>         then implement
> 
>     Decide how to expose optimistic transactions
>         then implement
> 
>     Decide how to expose attach/detach
>         then implement
> 
> Additional Work To Be Done In Grafolia
>     Support for arrays like collections (should be a trivial addition to 
> ManagedTrackerFactory)
> 
>     Make GraphAnalysis more useful -- OJB does a lot of munging right 
> now        consider adding client ability to define the visitor
> 
>     Optimize flushing algorithm for unmanaged or mixed 
> managed/instrumented graphs
> 
>     Make the reachability algorithm used by the Graph/Visitor combo a 
> component
> 
>     Refactor/Combine duplicated visitor functionality in Graph/Visitor 
> stuff
> 
> 
> The OJB code has been checked in to OJB CVS in the org.apache.ojb.dirty 
> namespace and is moderately unit tested, with good sample code in the 
> existing unit tests.
> 
> The Grafolia stuff is in db-commons-sandbox/grafolia at 
> http://db.apache.org/commons/sandbox/grafolia/ and has no released 
> binaries (is maven build and has no dependencies so should be 
> straightforwad to use in an IDE or on command line). It is pretty 
> thoroughly unit tested (clover says 81% with the untested mostly being 
> the "you cannot commit a closed transaction" type exceptions). The 
> DefaulUnitTest testcase is probably the best starting point for that 
> library.
> 
> Feedback, please!
> 
> Thanks,
> 
> Brian
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

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