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 Sat, 14 Aug 2004 20:14:03 GMT
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


Mime
View raw message