db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Dirty Take 2 (checked in) (feedback please!)
Date Sun, 15 Aug 2004 12:26:49 GMT
hi brian,

it looks like you delete PersistenceAwarePerson but did not remove or comment it 
in repository-junit.xml. i'll comment it in repository-junit is that ok ?

jakob

Brian McCallister schrieb:

> Okay, checked in a sub-interface of the PB which exposes the grafolia  
> unit associated with the current transaction.
> 
> I didn't wire up the unit.begin(), commit, and rollback to the PB ones  
> yet, but will now that I mention it.
> 
> Lazy insertion is done by inserting into the Unit, not the PB. The PB  
> does it immediately, Unit does it when flushed (Unit#flush(): void)  
> which is called before commit if you don't do it explicitly. The  
> implementation is a cheat right now, but is fastest way to get it in  
> for you.
> 
> Take a look at org.apache.ojb.dirty.UnitTest (I find the name  
> hilarious, it is a test to test the unit class, so... =) for a lazy  
> insertion example. Deletes aren't in, btw.
> 
> Unit#register will register an instance as PERSISTENT_CLEAN Unit#insert  
> and PERSISTENT_NEW.
> 
> -brian
> 
> On Aug 12, 2004, at 1:29 PM, Jakob Braeuchi wrote:
> 
>> hi brian, armin,
>>
>> calls to store and delete should only be intercepted if the broker is  
>> in transaction. imo we should not use the same methods for direct and  
>> lazy execution. i'm also not sure whether it's a good idea to add  
>> additional functionality to the broker, it will get closer to an otm  
>> then.
>>
>> jakob
>>
>> Brian McCallister schrieb:
>>
>>> 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


Mime
View raw message