db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kalén <mka...@apache.org>
Subject Re: Move 1.0.2 release to Tuesday, March 15th.
Date Mon, 14 Mar 2005 20:05:02 GMT
Armin Waibel wrote:
> after millions of test cycle I found the (main) problem. It's caused by 
> the collection proxy implementations in conjunction with an ObjectCache 
> implementation different than the ObjectCacheDefaultImpl, e.g. with 
> "empty cache" or with TLCache.

Tricky to track down, that one...

> Say we have an object with circular reference
> A1 -1:1-> B1 -1:n-> [A1,C]
> and the 1:n is a collection proxy.
> Now user lookup A1 and get A1@11->B1@12-->[proxy@]. He wants to remove 
> the C object in the 1:n reference in B@12. Because B has an proxy 
> collection, the proxy materialize on
> B.getC's().remove(1) ==> remove C
> call.
> While materialization of the collection proxy OJB lookup again an A1 
> instance. Because the previous materialzed A1@11 instance isn't in the 
> cache, so OJB lookup a new instance for A1 ==> A1@22 and a new B1@44
> Thus we have A1@11 --> B1@12 -->proxy@[A1@22[-->B1@44]-->A1@22] !!!!
> Needless to say this will cause problems on update.
> Any suggestions?

Is this new because of cache-changes and/or ODMG API cache-usage in 1.0.2?

If _not_ regression since 1.0.1, my suggestion is simply to document 
under known issues that "using the ODMG API with collection proxies and 
a cache implementation other than ObjectCacheDefaultImpl is known to 
cause problems on update, please do not use this combination in 
production environments with this relase of OJB".
(Or preferably something shorter). ;)

This way we could release 1.0.2 and get some time to solve this properly 
without the stress of an upcoming release.


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message