You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Kevin Sutter (JIRA)" <ji...@apache.org> on 2007/09/19 18:24:12 UTC
[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.
Re: [jira] Created: (OPENJPA-376) Need more trace for transaction demarcation
Posted by Kevin Sutter <kw...@gmail.com>.
On 9/19/07, Pinaki Poddar <pp...@bea.com> 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:jira@apache.org]
> >Sent: Wednesday, September 19, 2007 11:24 AM
> >To: dev@openjpa.apache.org
> >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.
>
RE: [jira] Created: (OPENJPA-376) Need more trace for transaction demarcation
Posted by Pinaki Poddar <pp...@bea.com>.
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
972.834.2865
>-----Original Message-----
>From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
>Sent: Wednesday, September 19, 2007 11:24 AM
>To: dev@openjpa.apache.org
>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.
[jira] Updated: (OPENJPA-376) Need more trace for transaction
demarcation
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick updated OPENJPA-376:
---------------------------------
Fix Version/s: (was: 1.2.0)
1.3.0
1.2.1
Moving to next release
> 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.2.1, 1.3.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.
[jira] Updated: (OPENJPA-376) Need more trace for transaction
demarcation
Posted by "Albert Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Albert Lee updated OPENJPA-376:
-------------------------------
Fix Version/s: (was: 1.0.1)
1.0.2
Defer to next release.
> 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.2, 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.
[jira] Updated: (OPENJPA-376) Need more trace for transaction
demarcation
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-376:
------------------------------------
Fix Version/s: (was: 1.0.2)
Removing from 1.0.2 as there doesn't seem to be much activity on this enhancement.
Regarding the enhancement itself: what events in particular are needed? In my experience, turning on SQL and JDBC logging has provided me with assurances about data getting sent to the database, and this includes transaction and thread ID information in the log.
Regarding the question about what trace channel to use: Runtime sounds reasonable; if it's already pretty noisy, then creating a new Transaction channel sounds reasonable too.
> 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.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.
[jira] Updated: (OPENJPA-376) Need more trace for transaction
demarcation
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-376:
------------------------------------
Fix Version/s: (was: 1.1.0)
1.2.0
> 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.2.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.