Re: RFC: OJB1.0 - CollectionProxies and per-thread metadata changes

[Armin Waibel <ar...@apache.org>]

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

Re: RFC: OJB1.0 - CollectionProxies and per-thread metadata changes

[Martin Kalén <mk...@apache.org>]

Armin Waibel wrote:
> 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?

I have modified:
org.apache.ojb.broker.metadata.MetadataManager [1]
org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl [2]
org.apache.ojb.broker.metadata.MetadataMultithreadedTest [3]

Changes:
[1]
* Introduced local variable "currentProfileKey", set when loading 
profile by key.
* Introduced new API method "getCurrentProfileKey" to read currentProfileKey

[2]
* Introduced local variable "_perThreadDescriptorsEnabled", set in 
constructor if per-thread metadata changes are active.
* Introduced local variable "_profileKey" with protected getter/setter, 
used to load profile when lazy-loading with per-thread metadata profiles.
* Added protected method "loadProfile" which will perform the
forementioned profile-loading.
* Added intercept calls to loadProfile before any data is loaded.

[3]
* Added new test method "testProxiedLoading" to provoke the bug fixed by 
changes #1 and #2.


Since the changes are transparent if one does not use per-thread changes 
and the only API-change is 1 added method, I will commit this on the 1.0 
release-branch. It makes using profiles+proxies a bit slower (profile 
loading overhead when materialising proxy), but prevents previously 
undefined behaviour with the occasional 
ClassNotPersistenceCapableExceptions.

Please review and let me know if you have any issues with the new code. 
I will update release-notes.txt accordingly.

Regards,
  Martin

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