incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: XMLBeans performance and source code status [Re: Proposal: XMLBeans]
Date Sun, 06 Jul 2003 14:56:14 GMT
David Bau wrote:

 >Adding a few links and other info -
 >Eric Vasilik writes:
 >>The synchronization described refers to the fact
 >>that one may manipulate the XML via the XmlCursor
 >>or the strongly typed XMLBean classes generated from
 >>the schema
 >As Eric says, we don't want to confuse the two uses of
 >the word "synchronize".  But since Aleksander brought it
 >up - here's some information on thread-synchronization
 >We examined both with- and without-thread-synchronized
 >access, and found that without-thread-sync, programmers
 >fall into traps like working with XML config files on
 >multiple threads in thread-unsafe ways without without
 >being aware of it.  We found that it costs between 1%
 >(strongly-typed access) and 10% (XmlCursor access) to
 >synchronize. So we're currently synchronizing access
 >to the data now, paying for more [app] stability with a
 >little bit of perf. We'd like to provide the option to
 >single-threaded (or savvy) users of not synchronizing
 >to get the 1-10% back. That's future work.

did you consider "fail quickly" approach that is used in Java 
collections (so for example Iterator can detect if it is used from more 
than one thread and fails if it happens)? the other possibility would be 
to allow making some objects  (such as configuration) immutable so can 
be safely shared between multiple threads.

 >As Eric pointed out, the key I think is not in what our
 >current numbers are, but the fact that we've isolated
 >our implementation from our interface so that we have
 >the flexibility of reducing allocations, deferring work,
 >and otherwise improving performance further in the future.
 >Abstracting the primary store behind a cursor rather
 >than a tree of objects with identity gives us some leeway
 >in shuffling our implementation strategy in the future
 >without restructing the APIs.
that sounds like very good strategy! however i winder what is really 
current state. when  i looked on source code and i could not see how 
layering could work (or it working already?): what parts are API a 
interfaces and how implementation is separated and can be switched - is 
this possible in current version to chose different implementation (by 
using for example factory pattern)? i can see it working for com.bea.xml 
(XSD types) and com.bea.xbean.values (implementation) - this is very 
valuable set of Java classes providing XSD validation (even more if they 
were more abstract so could be used with any XML databinding).



If everything seems under control, you're just not going fast enough. 
—Mario Andretti

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message