Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <411BA913.60400@gmx.ch>
Date: Thu, 12 Aug 2004 19:29:55 +0200
From: Jakob Braeuchi <jbraeuchi@gmx.ch>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT;
 rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: Dirty Take 2 (checked in) (feedback please!)
References: <6366AEDE-EA61-11D8-B6FA-000A95782782@forthillcompany.com>
 <411A8488.8050003@gmx.ch>
 <B075CCF0-EBE0-11D8-9B93-000A95782782@forthillcompany.com>
In-Reply-To: <B075CCF0-EBE0-11D8-9B93-000A95782782@forthillcompany.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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