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: State Tracking
Date Thu, 22 Jul 2004 23:38:55 GMT
Okay, as the one response I got back was a "proceed with broker stuff" 
i will do so.

Right now I will work on making the JDO 2 stuff work against the broker 
rather than OTM.

This means re-implementing a lot of what is in the OTM, however, with 
the OTM there, and experience gained working with it, this should be 
quite doable.

I am *not* going to initially aim for the full set of pluggable 
thingies the OTM does. Rather, I will work on making it possible to 
plug them, but not bother implementing until a need is expressed.

I have a good start on a state management and object graph manipulation 
library with no OJB dependencies. I am thinking of putting it in 
commons-db and letting OJB be dependent on it. It has the basics needed 
to handle the dirty detection (and optimized versions, including being 
able to implement the spit side of JDO); support for statement 
re-ordering (based on graph analysis with the fk relationships 
available); etc.

Would really appreciate feedback on all this. Is big decisions to be 
passed on "no one responds"

-Brian

On Jul 19, 2004, at 4:17 PM, Brian McCallister wrote:

> To answer the "why cannot yank OTM for the dirty.* stuff" question...
>
> The state tracking dirty does has a much smaller scope than the OTM. 
> It doesn't do object space transactions, locking, etc which is the 
> main point of the OTM (Object Transaction Manager). It is also less 
> flexible right now in that it doesn't support the various copy 
> strategies and isolation
>
> Right now the dirty broker stuff couldn't replace the features of the 
> OTM.
>
> That said, I am still worried about the OTM per previous post =)
>
> -Brian
>
> On Jul 19, 2004, at 7:39 AM, Robert S. Sfeir wrote:
>
>> Is OTM even in use by anyone besides Brian?  I haven't seen much 
>> traffic in the patch area for the OTM, is there a reason we can't 
>> yank it for the Dirty* changes?
>>
>> R
>>
>> On Jul 18, 2004, at 11:23 PM, Brian McCallister wrote:
>>
>>> The stuff I have been doing with o.a.o.broker.dirty.* has led me to 
>>> realize generalizing that state tracking is a pretty trivial step 
>>> beyond what it does now.
>>>
>>> I am thinking hard about writing a general state tracking and 
>>> unit-of-work library without an OJB dependency, then swapping out 
>>> the Dirty* stuff to use that library.
>>>
>>> Benefits to OJB
>>> 	Shrinks codebase
>>> 	Encourages reuse of modules (this would be a module)
>>> 	Provide transaction handling for transient instances
>>>
>>> Drawbacks
>>> 	Duplication of purpose with the OTM
>>> 	General solution will be slightly less perfect, probably
>>>
>>> The OTM worries me right now. It is extremely complex, has subtle 
>>> issues, the two primary creators of it are no longer working on it, 
>>> and the primary person now working on it (Oleg) doesn't actually 
>>> *use* it.
>>>
>>> -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
>>
>>
>> t
>
>
>
> ---------------------------------------------------------------------
> 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