db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [kernel refactoring] What do you think about
Date Sat, 22 May 2004 15:02:07 GMT
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 

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


> 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

View raw message