>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 >too. > >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. > hi,
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).
thanks,
alek
--
If everything seems under control, you're just not going fast enough. —Mario Andretti
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
