db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: Dirty Take 2 (checked in) (feedback please!)
Date Wed, 11 Aug 2004 02:09:54 GMT
Right now Grafolia uses an abstract factory to return per-instance 
state trackers for all non-immutable (String, Long, etc) types and 

The default impl (included in grafolia dist) does an equality and 
hashcode check on the contents of the collection.

One of the to-be-done things is to create an OJB TrackerFactory which 
can allow the managed collections to simply manage their own state with 
OJB -- they will, effectively, always report their state as CLEAN as 
far as grafolia is concerned.

The same mechanism allows for instrumented instances to track their own 
state, etc.

The various factories passed into the DefaultUnit constructor are the 
major points of configuration for this kind of stuff =)


On Aug 10, 2004, at 9:10 PM, Armin Waibel wrote:

> 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

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

View raw message