Hi Claudio, More comments inline below... On Wed, Aug 5, 2009 at 3:14 AM, Claudio Di Vita <[email protected]> wrote:
> > Kevin Sutter wrote: > > > > Hi Claudio, > > You mention in an earlier post that when you turn on SQL Trace that you > > see > > all of the Inserts getting created. So, does that mean that if you turn > > Trace on that it seems to affect the processing and everything works as > > expected? Or, do you see SQL in the Trace that is supposedly generated > > and > > executed, but it doesn't result in rows in tables? > > > > Have you turned on all of the TRACE to see if there are any errant > > exceptions not being surfaced? (If turning Trace on affects the ability > > to > > reproduce the problem, then this may not be a valid request.) > > > I turned on all TRACE messages, but I cannot see any exception. The SQL is > generated for all records, but I cannot see them as rows in tables. > Interesting. We don't generate and log the SQL until it's ready to be sent to the database. So, it's very strange that the TRACE all looks okay but the data is not getting to the database. Have you tried tracing your database to see whether all records are getting there and whether any exceptions are getting swallowed on that end? It's almost as if the SQL is getting generated and maybe even flushed to the database, but then the transaction is getting rolled back for some reason. Not making a lot of sense... Is it possible to share your TRACE file with a bit of explanation of how to interpret your processing? Kevin Sutter wrote: > > > > In your thread local method, you check if the EM is Open. If it's > Closed, > > then you create a new one. If it's Open, then you just continue to use > > it. > > Can you further explain your lifecycle processing for the EM? That is, > > who > > is responsible for Closing the EM when it's done? And, under what > > conditions? What transaction demarcation are you using? Local > > EntityTransactions or some external transaction manager? I'm just > > wondering > > if there's some hiccup between the opening/closing of the EM and the > > transaction demarcation processing. > > > > BTW, I agree with Craig's earlier comment that there should be no reason > > to > > use the Multihhreaded property if you are only using a single EM per > > thread. And, if you set this openjpa.Multithreaded to "true", then the > > problem does not surface? If that's the case, then it seems that you are > > accidentally using an EM by more than one thread. I just don't see how > > yet... > > > > The EM provided by the ThreadLocal is used by some utility methods that > perform persistence operations and then close the EM. So I have to check > the > state of the EM stored in the ThreadLocal, but there aren't "pending" EM. > > I use local transactions...maybe I should try with a standalone JTA > provider > ?? Well, this might be easier said than done. By an external JTA provider, I meant one provided with an application server. I am not aware of a JTA provider that runs in JSE. The local transactions should be just fine. I'm just wondering whether these local transactions are getting properly committed before closing of the corresponding EntityManager. This might explain some of the unexpected rollbacks that I was guessing at above... Kevin > > > > ----- > Not everything that can be counted counts - Albert Einstein > > http://www.linkedin.com/in/cdivita > -- > View this message in context: > http://n2.nabble.com/Persist-issue-in-multithreaded-environment-tp3377510p3389868.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
