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:53:23 GMT
Speaking to that -- binding for lazy insertion should be to the 
transaction, not the connection, though inserting dependencies for 
eager insertion seems reasonable.

What are your thoughts on how it should behave?

-Brian

On Aug 11, 2004, at 5:52 PM, Brian McCallister wrote:

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



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