db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: State Tracking
Date Fri, 23 Jul 2004 12:20:06 GMT
Hi Brian,

Brian McCallister wrote:

> Okay, as the one response I got back was a "proceed with broker stuff" i 
> will do so.
> 

Sorry for the "contempt", I currently concentrate my energy on the 1.1 
stuff and was lazy in reading mails ;-)


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

hmm, I must admit that I'm not familiar with the OTM stuff, so I can't 
estimate the 'best solution'.
But I think we should move as much services as possible to the kernel, 
see here
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgId=1753384


> 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. 

Is this really possible without complex operations or mappings? Don't 
you need the proprietary object metadata classes (PK keys, FK, 
relationships, ...) to handle this stuff?

regards,
Armin


> 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
> 
> 
> 

---------------------------------------------------------------------
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