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