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: RFC: OJB1.0 - CollectionProxies and per-thread metadata changes
Date Wed, 17 Nov 2004 13:30:41 GMT
Hi Martin,

 > The problem with OJB 1.0 is that this configuration (i.e. per-thread
 > metadata changes and any CollectionProxy instance) is undefined. The
 > proxy is no longer a true proxy, since loading the data might or might
 > not succeed depending on in which thread it is loaded.

Agree with you.


 > I have created a local fix on the 1.0 branch that will:
 > a) allow usage of per-thread metadata changes and profile keys with
 > dynamic proxies (by storing a reference to the key used while creating
 > the proxy, in the same fashion a reference to a broker key is stored)
 >
 > b) throwing an exception if per-thread metadata changes are activated,
 > but no profile loaded while creating the CollectionProxy.
 >

Which classes will be affected? Do need any api changes?

regards,
Armin


Martin Kalén wrote:
> Greetings,
>  the company I'm currently working for have used per-thread metadata 
> changes and "OJB-profiles" extensively for running two OJB-based 
> back-ends with conflicting table-/mapping names in the same servlet.
> 
> The servlet will "boot" OJB with an empty repository containing only 
> internal mappings - this way it does not matter which back-end will win 
> the race of loading it's profile first. Both contain identical 
> ojb-internal repositories.
> 
> When a back-end is first referenced, a static initializer activates 
> per-thread metadata changes in MetadataManager, loads the 
> back-end-specific class mappings and stores these in MetadataManager 
> using a String-key.
> 
> Some meta-code snippets:
>  MetadataManager mm = MetadataManager.getInstance();
>  mm.setEnablePerThreadChanges(true);
>  DescriptorRepository repository = mm.copyOfGlobalRepository();
>  DescriptorRepository descriptors;
>  descriptors = mm.readDescriptorRepository("current back-end's 
> repository file.xml");
>  mm.mergeDescriptorRepository(repository, descriptors, false);
>  mm.addProfile("current back-end's string-key", repository);
> 
> Anytime OJB is used, the back-end specific mappings are activated using 
> a wrapper method that will do:
>  MetadataManager mm = MetadataManager.getInstance();
>  mm.loadProfile(key);
> 
> So far so good.
> 
> 
> Now; the object's loaded are sometimes huge object graphs so we are also 
> using CollectionProxies for collections that might reference a large 
> amount of data.
> 
> The problem with OJB 1.0 is that this configuration (i.e. per-thread 
> metadata changes and any CollectionProxy instance) is undefined. The 
> proxy is no longer a true proxy, since loading the data might or might 
> not succeed depending on in which thread it is loaded.
> 
> I have created a local fix on the 1.0 branch that will:
> a) allow usage of per-thread metadata changes and profile keys with 
> dynamic proxies (by storing a reference to the key used while creating 
> the proxy, in the same fashion a reference to a broker key is stored)
> 
> b) throwing an exception if per-thread metadata changes are activated, 
> but no profile loaded while creating the CollectionProxy.
> 
> 
> What are you thoughts - especially on b? I'll try to clean up the code 
> and send a diff to the list so you can see for your self.
> 
> I think it's better to throw this hard exception than to get the 
> undefined behaviour with subtle "ClassNotPersistenceCapable"-exceptions 
> if the proxy data is later loaded in a thread without a loaded OJB 
> profile (or a different one for that matter).
> 
> Regards,
>  Martin
> 

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