[
https://issues.apache.org/jira/browse/OPENJPA-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845984#action_12845984
]
Pinaki Poddar commented on OPENJPA-1565:
----------------------------------------
1. Note the SQL Error State and Code of the SQL Exception when it fails to
throw expected exception
2. Check sql-error-state-codes.xml for that database dictionary. The error
states are categorized in that file. If the observed error does not occur in
the list of error states, add it (the error state not the error code).
3. Also check corresponding DB dictionary implementation isFatalException() and
ensure that it returns false when query/lock timeouts are intended to be
raised.
4. Returning false from isFatalException() will ensure that at facade level the
transaction is not rolled back.
> QueryTimeOut and LockTimeOut exceptions are not raised correctly
> ----------------------------------------------------------------
>
> Key: OPENJPA-1565
> URL: https://issues.apache.org/jira/browse/OPENJPA-1565
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, jpa, kernel, query, sql
> Affects Versions: 2.0.0-M1, 2.0.0-M2, 2.0.0-M3, 2.0.0-beta, 2.0.0-beta2
> Reporter: Pinaki Poddar
> Assignee: Pinaki Poddar
> Fix For: 2.0.0
>
>
> Narrowing SQL Exception to a more specific exception such as lock or query or
> referential integrity violation does not distinguish correctly whether a
> query or lock request has timed out.
> This distinction is critical for JPA 2.0 spec compliance because QueryTimeOut
> and LockTimeOut exceptions are not supposed to cause rollback as per the spe
> (Section 3.9).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
