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 22:22:47 GMT
Will add a mechanism for getting ahold of the unit in a few minutes...  
won't be a permanent solution, but will allow testing, etc.

-Brian

On Aug 11, 2004, at 6:16 PM, Brian McCallister wrote:

> yes, though for persistence-by-reachability according to JDO, this  
> would need to be inserted if person were inserted.
>
> auto-update here is an option, but for a lazy insertion (get the  
> grafolia unit associated with the pb transaction and use  
> Unit#insert(..)), the callbacks would evaluate the ordering at insert  
> time for this.
>
> -Brian
>
> On Aug 11, 2004, at 6:07 PM, Armin Waibel wrote:
>
>> I think this test fails because the auto-update flag is not set to  
>> 'true' or 'object' and OJB use 'false' as default and 'false' was  
>> mapped to 'link', thus the FK was set in Person but the Address was  
>> not stored.
>>
>> Armin
>>
>> Brian McCallister wrote:
>>
>>> 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
>>
>> ---------------------------------------------------------------------
>> 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