Re: Massive concurrency problems under high server load

[Armin Waibel]

Hi Gerhard,
this sounds alarming :-(
Gerhard Grosse wrote:
So my main questions are:
- Have substantial things changed between RC5 and 1.0 that might have
improved OJB's behavior under high concurrent load.
we made serveral improvements between rc5 and 1.0. The performance 
improvement of the odmg-api should be about 10-15%. The handling of 
nested objects was improved significantly (~ 250% better performance).
But I think this will not solve the described problems of transactions 
take minutes to complete.
OJB was shipped with a simple multi-threaded performance test. This test 
pass on all releases (but only on my single cpu PC).


- Does anyone have experience with OJB in a servlet environment under
high load? Any hints how to get it to work and perform? 

One finding that discourages us from upgrading to 1.0 is a concurrency
bug we discovered in RC5 which does not seem to have been fixed in
1.0:
In class org.apache.ojb.broker.core.QueryReferenceBroker:
private void performRetrievalTasks()
{
  while (m_retrievalTasks.size() > 0)
  {
      HashMap tmp = m_retrievalTasks; // *
      m_retrievalTasks = new HashMap(); // *
      // during execution of these tasks new tasks may be added
      for (Iterator it = tmp.entrySet().iterator(); it.hasNext(); )
      ...
the two lines marked with // * must be put in a block that
synchronizes (e.g.) on m_retrievalTasks. If not, a thread switch may
occur after the first line and two instances of tmp may point to the
same hash table. Seems unlikely, but under high load it does occur
often enough (a java.util.ConcurrentModification exception is the
consequence):
synchronized (m_retrievalTasks) {
  tmp = m_retrievalTasks;
  m_retrievalTasks = new HashMap();
}
solves the problem.
hmm, the PB-api is not threadsafe by design, so if this happens the 
problem will be occured by the odmg-api (missing synchronized block ...) 
or does it happen when lazy loading of objects was used?

regards,
Armin

Any hints and help are greatly appreciated.
Gerhard Grosse



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]