|
|
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@xxxxxxxxxxxxx
For additional commands, e-mail: ojb-dev-help@xxxxxxxxxxxxx
|
|