Re: patch.txt

[Jochen Wiedmann <jo...@gmail.com>]

Dean Hiller wrote:

> two different implementations....not bad wouldn't mind at all.  Were 
> would we put this new class though?  I would like to see it no break 
> when the configuration stuff is overhauled.

Doesn't matter. If it is there, and there is a unit test for its 
features, then we'll know if future changes break the feature.



> synchronization.....IMO.  I would like to stay away from 
> synchronization.  I am developing a very high performance platform.  I 
> have done this with castor before and no synchronization.  Also, the 
> JAXB spec team was saying they want to do this without without 
> synchronization.

I absolutely do not follow the JAXB spec team here. The JAXBContext is 
explicitly designed for being thread safe. However, a modifiable 
JAXBContext is either not thread safe or synchronized. That's a fact.

Besides, I do not understand why the performance impact of 
synchronization should be so dramatically: Consider the case of 
marshalling to a Writer or InputStream. The writers and input streams 
are typically synchronized. In other words, marshalling will typically 
involve several hundred or thousand synchronized accesses to the target 
object. On the other hand, requesting the Manager object from the will 
add a single synchronized access to the JAXBContext. What's the story?


> The trick to not having synchronization is using the 
> feature of java that lets you change a reference atomically...ie.

No, that's simply not sufficient. It's like assuming that using a 
Hashtable (aka synchronized Map) will make an application thread safe. 
You are missing the gap between reading information and updating 
information.


> Another way is to just use a synchronized Hashtable to.

A Hashtable *is* a synchronized object. As for performance, it doesn't 
matter, which object is being synchronized: The JAXBContext or the 
Hashtable. Besides, I have already pointed out that using a Hashtable 
won't make the code thread safe.


> I believe there 
> is no reason to use synchronization unless I have mistakes in my code 
> and in that case, I should fix the mistakes instead of using 
> synchronization.

Is your application threaded? If so, you need some style of 
synchronization, however it might look like. If you are doing that for 
yourself, then you don't do it at the logical place. (Which is as near 
to the critical objects aka Manager maps as possible.) This is far more 
error prone than doing it at the natural point.


> classloaders(registerClassLoader).  I am confused why you would separate 
> the registerClassloader and registerPackages method.  What would 
> registerClassLoader do?

I simply do not see a reason why additional packages need another 
classloader. There may be a reason in your application but that's 
unrelated to the process of extending the manager map.

Even more important: The JAXBContext was designed (with very good 
reason!) to have a single ClassLoader. To me the "registerClassLoader" 
method means extending that single ClassLoader and not extending the 
internal map of managers.


Jochen

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