Re: Massive concurrency problems under high server load

[Armin Waibel]

Hi again,
>
> I think this one happend during lazy loading of a list proxy. So would
> this mean that
> - we should not use reference and collection proxies when working with
> the ODMG API (this would be a heavy blow)
In a normal servlet environment this should be work. Only when using OJB 
within EJB it is not possible to use lazy loading, because the client 
(e.g. webserver in 3-tier environment) does not know about OJB (or the 
collection proxy itself has to be a bean).

> - or that we should not use objects with unmaterialized proxies
> outside of a transaction? (I think we don't do that normally, but
> there might be some cases where we do.)
hmm, this should work. Could you describe more exactly what your test 
do? Does the test operate on the same objects, does insert new object, 
read, delete,... Were does the issue happen?

It will be time-consuming but we first need to reproduce your issue with 
an standalone unit-test.

regards,
Armin
Gerhard Grosse wrote:
Hi Armin,
some comments below, more in my response to your second post.
On Fri, 20 Aug 2004 19:47:25 +0200, Armin Waibel <[EMAIL PROTECTED]>
wrote:

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).

Which probably means we will upgrade as soon as we have a little more
time.


- 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?


I think this one happend during lazy loading of a list proxy. So would
this mean that 
- we should not use reference and collection proxies when working with
the ODMG API (this would be a heavy blow) 
- or that we should not use objects with unmaterialized proxies
outside of a transaction? (I think we don't do that normally, but
there might be some cases where we do.)

Thanks,
Gerhard


---------------------------------------------------------------------
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]