On 9/19/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote: > > Like the idea of TXN channel which traces > all transaction-related events (begin/commit/rollback) > + flush > + registration/synch to external Txn managers. > With SQL and TXN channel open one can glean a fair amount of critical > details without switching on the whole Runtime to TRACE.
Yes, that would be the point. Just didn't know if adding another channel was a desired step or not... Thanks for the input. Kevin Pinaki Poddar > 972.834.2865 > > > >-----Original Message----- > >From: Kevin Sutter (JIRA) [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, September 19, 2007 11:24 AM > >To: [email protected] > >Subject: [jira] Created: (OPENJPA-376) Need more trace for > >transaction demarcation > > > >Need more trace for transaction demarcation > >------------------------------------------- > > > > Key: OPENJPA-376 > > URL: https://issues.apache.org/jira/browse/OPENJPA-376 > > Project: OpenJPA > > Issue Type: Bug > > Components: jdbc > > Affects Versions: 1.0.0 > > Reporter: Kevin Sutter > > Assignee: Kevin Sutter > > Fix For: 1.0.1, 1.1.0 > > > > > >As we are debugging problems in an application server > >environment (ie. WebSphere), it is becoming apparent that we > >need more trace output when demarcating transaction > >begin/commit/rollback. I have had to debug several problems > >relating to whether data updates were actually pushed out to > >the database or not. Without turning on additional trace > >mechanisms in other software components (WebSphere, the > >database itself, the application, etc), it's impossible to > >tell what OpenJPA is processing as far as the transaction is > >concerned. This becomes increasingly important when dealing > >with multiple clients and multiple transactions and knowing > >what gets processed in what order. > > > >Question: What trace channel should I use? Should I go with > >the general openjpa.Runtime channel? Or, should I create a > >new channel (openjpa.Transaction)? Seems like overkill. But, > >if people are concerned about the amount of trace data, we > >could go this route. Suggestions? > > > >Kevin > > > >-- > >This message is automatically generated by JIRA. > >- > >You can reply to this email to add a comment to the issue online. > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and > have received this message in error, please immediately return this by email > and then delete it. >
