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:[EMAIL PROTECTED]
Sent: Friday, October 24, 2008 5: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.
