[
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.
