xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bau" <David....@bea.com>
Subject RE: XMLBeans performance and source code status [Re: Proposal: XMLBeans]
Date Mon, 07 Jul 2003 15:56:45 GMT
Aleksander Slominski wrote:
> 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.

Yes, we considered sync-free "fail fast" for working with
immutable data.  You are thinking along the same lines
we have been as well.

As far as we've been able to figure out (so far),
sync-free mulithreaded access to immutable instances
appears to require us to pay for all the work up-front
instead of on-demand.  (If, for example, you want to
compute and remember the Calendar object the first time
somebody has read a xs:dateTime, you need to write it
somewhere, and as soon as you write anything without
managing synchronization you end up with race
conditions, especially given the out-of-order-write
issue with the Java memory model....)  So sync-free-
read-only-multithreading is not (yet) implemented.
It is a potentially interesting area for experiments
and measurement, but honestly probably a lot of work
too.

On the other hand, enabling sync-free single-threaded
use seems to me like a clear thing to want to do, and
probably significanly easier.

> 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 

We've separated the public APIs in com.bea.xml.* from their
implementations in the other packages.  In particular,
you can see our implementation of the cursor and the
store are in com.bea.xbean.store.*, while users only ever
hold on to the abstract interfaces com.bea.xml.XmlCursor
or com.bea.xml.XmlObject.

There is an XmlFactoryHook class that can be used to register
interceptors for the (nonabstract) Factory methods, and this can
be used to supply alternate implementations of XmlObject and
XmlCursor. But this is a very coarse mechanism.  As you observe,
further factoring might make it eaiser to pick and choose
alternate implementations for bits and pieces. So even though
the public APIs are designed with layering in mind, being able
to take out or plug in alternate implementations of different
components is future work. It's probably appropriate to do as
applications require it. (It should be doable, and if you have
a project in mind we'll want to get you involved.)

David Bau

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message