openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <>
Subject RE: [jira] Created: (OPENJPA-376) Need more trace for transaction demarcation
Date Wed, 19 Sep 2007 16:50:29 GMT
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.  

Pinaki Poddar

>-----Original Message-----
>From: Kevin Sutter (JIRA) [] 
>Sent: Wednesday, September 19, 2007 11:24 AM
>Subject: [jira] Created: (OPENJPA-376) Need more trace for 
>transaction demarcation
>Need more trace for transaction demarcation
>                 Key: OPENJPA-376
>                 URL:
>             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?
>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.

View raw message