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 21:52:07 GMT
pb.store(..) will execute immediately, which doesn't allow for 
re-ordering.

It would be possible to do it all lazily, but would then need to 
intercept calls to store(..) and delete(..). The re-ordering, right 
now, only works on lazy insertions, such as ODMG uses (tx.lock(..)).

-Brian

On Aug 11, 2004, at 4:41 PM, Jakob Braeuchi wrote:

> hi brian,
>
> i'm playing a little bit with the DirtyBrokerTest.
> i added a method to insert a new person and it's new mainAddress:
>
>         broker.beginTransaction();
>         Person person = new Person();
>         person.setFirstname("Brian");
>
>         Address mainAddress = new Address("USA", "Wilmington-Main", 
> "Wombat Court");
>         person.setMainAddress(mainAddress);
>
>         broker.store(person);
>         broker.commitTransaction();
>
> this test fails with an integrity constraint violation because the 
> person is inserterted before the mainAddress.
>
> (core.PersistenceBrokerImpl          776 ) Cascade store for this 
> reference-descriptor (mainAddress) was set to false.
> 1092256841968|0|0|statement|INSERT INTO OTM_PERSON 
> (ID,FIRSTNAME,LASTNAME,MAIN_ADDRESS_ID) VALUES (?,?,?,?) |INSERT INTO 
> OTM_PERSON (ID,FIRSTNAME,LASTNAME,MAIN_ADDRESS_ID) VALUES 
> ('166','Brian','','164')
>
>
> jakob
>
> Brian McCallister schrieb:
>
>> 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


Mime
View raw message