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]
