db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kalén <martin.ka...@curalia.se>
Subject RFC: OJB1.0 - CollectionProxies and per-thread metadata changes
Date Mon, 04 Oct 2004 14:07:29 GMT
  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();
  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();

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


Martin Kalén  |  Systems Designer
Curalia AB  |  www.curalia.se
Tjärhovsgatan 21, SE - 116 28 Stockholm, Sweden
Phone: +46 (0)8-410 064 40

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

View raw message