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: AutoDirty in PB
Date Tue, 06 Jul 2004 12:56:29 GMT
Speaking of the checkin on this...

next step is to provide hooks for instances to be aware of dirty 
checking and provide for managing their own state. This should 
*greatly* speed up commits and provide for much better memory usage.

One question on this -- would people prefer a JDO-like 
PersistenceCapable interface which needs to provide exactly the fields 
that were changed, or would a simpler interface which merely provides 
hooks for state management be sufficient?

Along with this i will include an AspectJ aspect which can be used to 
enhance pretty much any class to do state migrations on field writes 
and implement the interface at compile time.

Major benefit of all this is that we would no longer need copy-on-read 
and compare-on-commit. Could do that for non-aware instances, but for 
anything aware we can simply trust that it managed its state correctly 
and commit what was reported.

This will be done via subclassing the Entry and using different Entry 
impls depending on the type being loaded, and by storing the entries by 
state, with a new-ish state (possibly) of PERSISTENT_UNKNOWN for ones 
which require compre-on-commit.

Feedback please!

-Brian

On Jul 6, 2004, at 6:49 AM, Brian McCallister wrote:

> Will check in as it is totally independent (doesn't require changes to 
> anything else).
>
> Basically it is just hooking two listeners to a persistence broker and 
> giving them a means to communicate. I set it up vie a different 
> PBFactory, but a better way may be to make the current PBFactory able 
> to hook things in.
>
> Will check in later this morning. I want to make some changes for my 
> own use going forward, so count on it being unstable for a while. 
> Basically -- can optimize it much further than it already is ;-)
>
> -Brian
>
> On Jul 6, 2004, at 5:24 AM, Armin Waibel wrote:
>
>> Hi Brian,
>>
>> +1, I don't know your implementation in detail, but sounds good to me.
>> Is it configurable at runtime (enable/disable auto-dirtying)?
>>
>> Armin
>>
>> Brian McCallister wrote:
>>> I have a PersistenceBroker implementation (really just a set of 
>>> listeners on the regular PB) which handle auto-dirtying at the 
>>> persistence broker level via copy-on-read and compare-on-commit.
>>> It is less functional than the OTM in that it doesn't handle 
>>> isolation etc, just performs its behavior at the PB level. This is 
>>> identical behavior to the Hibernate Session, which a lot of people 
>>> seem to like, so I was wondering, now that 1.0 is out, if there was 
>>> any interest in making this available in the OJB directly, or simply 
>>> work on the OTM level. Advantage is that it is more performant and 
>>> much less code than OTM.
>>> -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


Mime
View raw message