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: [kernel refactoring] What do you think about
Date Sat, 22 May 2004 15:07:40 GMT
+1 on all changes, but let's push 1.0 first. This gives us (more) major 
incentive to get 1.0 out the door Real Soon Now (tm).

I am making time this weekend to (finally) tackle the docs stuff you 
and Thomas D. mentioned, so hopefully can make some good reorg progress 
on that.

Frankly, I wouldn't let doc reorg hold back 1.0 though. We can push new 
versions of docs independently of releases.


On May 22, 2004, at 11:02 AM, Jakob Braeuchi wrote:

> hi armin,
> Armin Waibel wrote:
>> Hi all,
>> after a hint from Brian to change the the default cache 
>> implementation to ObjectCachePerBrokerImpl, because that one makes 
>> most sense in real deployments I start writing a real two level cache 
>> to improve cache possibilities and hell came over me, so I do some 
>> more....
>> I introduce a class called LocalCache (replace InternalCache in 
>> PBImpl). This class implements ObjectCache interface and provide some 
>> additional methods. It wraps the ObjectCache instance provided by the 
>> ObjectCacheFactory.
>> LocalCache represents a first level cache and is not pluggable. All 
>> cached objects first be cached in LocalCache and will be pushed to 
>> the real cache when the PB-tx successfully commits or when method 
>> #pushToRealCache() was directly called. In all other cases the cached 
>> objects will be discarded.
>> It guarantee transaction isolation of the ObjectCache (as long as we 
>> don't use all persistent objects by reference), help to resolve 
>> circular references and help to avoid concurrency materialization 
>> problem of the global ObjectCache implementations (means that partial 
>> materialized objects can be read from a global shared cache by a 
>> concurrent thread).
>> Now all test cases pass (except some tests which should fail) with 
>> ObjectCacheEmptyImpl too and I think this will be expected by the 
>> user.
>> I'm currently working on a new second level cache (ObjectCache) which 
>> returns only copies of the cached objects and internally cache only 
>> "flat objects" (field values + Identity objects of the references). 
>> At present it's in an alpha state.
> this could help us update only the changed attributes of an object 
> (like toplink does).
>> Second I introduced a separation of the PB user api and the PB api 
>> used by the top-level implementations. The PersistenceBroker 
>> interface was extended by PersistenceBrokerInternal interface. In PBI 
>> all services and methods useful for top-level api can be specified.
> sometimes you can see SPI (Service Provider Interface) for internal 
> use and API for external use.
>> PersistenceBrokerFactoryFactory now returns PBI instances instead of 
>> PB, but the good all PBF still returns PB instances. So the changes 
>> will only be visible internal.
>> The top-level api should use in future 
>> 'PersistenceBrokerFactoryFactory.instance()' to get instances of PBI.
>> Third I introduce an Identity service help to create Identity 
>> instances of given objects.
>> In PBImpl:
>> public IdentityFactory serviceIdentity();
>> IdentityFactory provide methods for easy creation of Identity 
>> instances.
>> Also I introduced in PBImpl
>> public void setIgnoreCache(boolean ignore);
>> public boolean isIgnoreCache();
>> 'setIgnoreCache' allows to temporarily disable the ObjectCache 
>> (LocalCache was still active to help proper materialization of 
>> objects), e.g. when big ResultSets are expected and you don't want to 
>> push millions of objects to cache.
>> Till now all described changes and improvements should be backward 
>> compatible and do NOT affect user api. All tests pass and performance 
>> was not affected.
>> But why not add
>> public IdentityFactory serviceIdentity();
>> public void setIgnoreCache(boolean ignore);
>> public boolean isIgnoreCache();
>> to PB interface. This will be backward compatible and offer new 
>> helpful services to PB user api. I know we are in RC (till one year 
>> now ;-)) and
>> api changes are not allowed, but why not break rules when it's good 
>> for all.
> i'd prefer to have 1.0 real soon, so we could concentrate on many 
> improvements.
> jakob
>> All comments welcome!
>> regards,
>> Armin
>> ---------------------------------------------------------------------
>> 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

View raw message