Hi Paul,
When doing "local" updates a simple synchronization is done on the synchronization domain of that XMLObject, we call it Locale. By default, each new document XMLObject is created with a new Locale. But when there is an update operation involving XMLObjects from two Locale-s, we're using a Global lock for a short time to get the locks on the two locales and avoid deadlocks. See code at org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:~2049) . Most probably your application is doing lot's of set's or the JVM is not optimized for this situation. Did you try using a different JVM, 1.6 or JRockit? Or you can modify your app to have XMLObjects created in the same Locale, this way avoiding GlobalLock. There is a non backwards compat option, Locale.USE_SAME_LOCALE that can be used when creating a new XMLObject to have it created in the same Locale as a different XMLObject. Cezar ________________________________ From: Paul Hepworth [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2008 7:00 AM To: [EMAIL PROTECTED]; [email protected] Subject: XmlBeans and Synchronization Hi (included dev list as this may be too in depth for the user list) I'm using XmlBeans 2.3.0 in a Weblogic 9.2 J2EE web application (JVM 1.5.0_10). We use XmlBeans to compile our schema and these effectively become our domain objects. These are looked up from the DB, stored in the Http Session, manipulated from the UI and passed to the DB again. The application appears to run fine with a single user, however when we test it with multiple users using LoadRunner, we hit issues. What we are seeing is that we're getting stuck threads with the following stack: at java.lang.Object.wait(Native Method) - waiting on <0xd4a816e8> (a org.apache.xmlbeans.impl.common.Mutex) at java.lang.Object.wait(Object.java:474) at org.apache.xmlbeans.impl.common.Mutex.acquire(Mutex.java:33) - locked <0xd4a816e8> (a org.apache.xmlbeans.impl.common.Mutex) at org.apache.xmlbeans.impl.common.GlobalLock.acquire(GlobalLock.java:27) at org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:1944) at ...MyClassImpl.setMyValue(...) Can anyone shed any light on why this may happen? More specifically, does anyone know what the synchronisation strategy is in XmlBeans. From my investigation, the GlobalLock uses a static Mutex, which means that if an instance needs to take out more than 1 lock, it attempts to acquire a GlobalLock and will subsequently lock out all other threads in the JVM from making any changes to an XmlObject. If that's the case, it seems very strange that making an update to 1 instance of an XmlObject would lock out all other threads form updating any other instance of an XmlObject. I would have thought that the synchronisation would have solely been around the instance itself. We have also seen the same issues that have been recorded here: https://issues.apache.org/jira/browse/XMLBEANS-328 Any help on this would be much appreciated as it's causing major issues!! Thanks Paul This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies. Detica Limited is registered in England under No: 1337451. Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
