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: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
