You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@xmlbeans.apache.org by Paul Hepworth <Pa...@detica.com> on 2008/10/24 14:00:27 UTC

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:194
4)

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.

RE: XmlBeans and Synchronization

Posted by Cezar Andrei <ce...@oracle.com>.

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:Paul.hepworth@detica.com] 
Sent: Friday, October 24, 2008 7:00 AM
To: user@xmlbeans.apache.org; dev@xmlbeans.apache.org
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.

RE: XmlBeans and Synchronization

Posted by Cezar Andrei <ce...@oracle.com>.

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:Paul.hepworth@detica.com] 
Sent: Friday, October 24, 2008 7:00 AM
To: user@xmlbeans.apache.org; dev@xmlbeans.apache.org
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.

RE: XmlBeans and Synchronization

Posted by Radu Preotiuc-Pietro <ra...@oracle.com>.

Hi Paul,

I can tell you what the synchronization strategy is. Each XmlObject belongs to an xml document, and each xml document belongs to what XmlBeans calls a Locale object (nothing to do with the Java Locale). This is the synchronization domain for XmlBeans. When doing a set, there are two XmlObjects involved: the source (the parameter of the "set" method) and the target (the object you're calling "set" on). XMLBeans requires that they both be synchronized. Now, if the synchronization domain for the two is the same (the same Locale object), then there's no problem (see check at XmlObjectBase.java:1934 if you have the 2.3.0 source). But if the syncrhonization domain is not the same, then it means that two locks must be acquired and so there is a possibility for deadlock. In order to avoid the deadlock, XMLBeans has the "GlobalLock". This global lock is held only for as long as it is necessary to acquire the two XmlObject locks and then it is immediately released. This guards against the deadlock, but doesn't guard against the possibility that one thread grabs the global lock and then blocks on waiting for another thread to finish with one of the XmlObject locks it is trying to acquire. Eventually, it will grab the lock it is waiting for and then release the Global lock, but while it is waiting, all the other threads in the whole system are prevented from initiating a set that requires two locks, which can be a problem.

So I think first of all, it would be interesting for you to look at the stack traces for all the threads to confirm my scenario above. Then, as far as solution, the only reliable one that I know of is not use the "setMyValue" method and replace it with "addNewMyValue" whenever possible because it doesn't require synchronization (and the overall performance is better). In XMLBeans 2.4.0, I think, removing synchronization altogether from the XMLBeans layer would also solve the problem.

Radu

________________________________

From: Paul Hepworth [mailto:Paul.hepworth@detica.com]
Sent: Friday, October 24, 2008 5:00 AM
To: user@xmlbeans.apache.org; dev@xmlbeans.apache.org
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

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.