You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by George Mardale <gi...@delsyne.ro> on 2004/12/13 15:07:38 UTC

multithreaded PersistenceManager

Hi everybody,

First of all, it's the fourth time I am asking for your opinion on this 
list, but until now no one replied. I don't know why this happens, since 
all my previous problems were related to simple OJB usage scenarios that 
failed to work in my case (just as an idea, we had to do some 
'workarounds' to avoid these really annoying problems, so they were 
never considered fixed).
I thought some of you have already experienced those problems. Maybe the 
problem was the fact that I am using OJB's JDO API (the plugin to 
JDORI). Who knows... The fact is that I found this particular API 
incredibly immature. I definitely don't recommend it to anybody. In my 
case, it is for sure the first and last time when I am using OJB's JDO 
API. I cannot say anything about PB API, but JDO API is a nightmare.

But anyway, I am sharing my problems again, maybe this time I will get 
lucky. So, as I said, I am using JDO API for developing a web 
application that needs multithreading support. My question is: what is 
the recommended approach for having multithreaded persistence managers?

We've already tried 2 approaches and both of them fail misserably:
1. we tried to get one persistence manager (for all clients) from the 
persistencemanagerfactory and set it to multithreaded (i.e., 
setMultithreaded(true)), but during concurrent access (i.e., multiple 
browser accessing same data at the same time), this fails with 
"transaction not active" or "transaction already started to commit"-like 
exceptions.
2. we tried to get one persistence manager per thread (i.e., each tread 
with its own persistence manager --- using ThreadLocal to store each 
thread's persistence manager). This works better than the first 
approach, but from time to time, we get "Instance .... not bound to the 
persistence manager of the query" exceptions. We couldn't create a 
step-by-step algorithm to reproduce the problem, but it seems that most 
of the times this exception appears after the appplication server (we 
use BEA"s WebLogic) switches the thread on which the web app runs (for 
us, new thread -> new persistence manager -> probably OJB's cache gets 
mixed up?!).

Any comments are greatly appreciated.

Thanks in advance,
George.

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org