openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heath Thomann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-1550) When batchLimit=-1 or >1 and an exception is caused, the params and failedObject are missing from the resultant exception.
Date Wed, 24 Mar 2010 22:55:27 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849514#action_12849514
] 

Heath Thomann commented on OPENJPA-1550:
----------------------------------------

Let me comments on the patches I just attached:

OPENJPA-1550v2.diff.txt is for 1.2.x. 
OPENJPA-1550-13x-v2.diff.txt is for 1.3.x
OPENJPA-1550-trunk-testcase.patch.txt is for trunk.

These patches add code to allow the 'failed object' to percolate up to the RollbackException
which results in the use case.
In addition, the trunk version of the patch fixes the test failures as outline by Donald.

For history sake, let me comment on the other patches already committed:

These patches are for 1.3.x:
OPENJPA-1550-13x.patch - this is the initial code change committed.
OPENJPA-1550-13x-testcase.patch.txt - this one adds some additional code plus the test case.

This patch is for trunk:
OPENJPA-1550-trunk.patch - this is the initial code change committed.

And this patch is for 1.2.x:
OPENJPA-1550.diff.txt - this is the initial code change committed plus the test case.

> When batchLimit=-1 or >1 and an exception is caused, the params and failedObject are
missing from the resultant exception.
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1550
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1550
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.2.2, 1.3.0, 2.0.0-beta2
>            Reporter: Heath Thomann
>            Assignee: Donald Woods
>            Priority: Minor
>             Fix For: 1.2.3, 1.3.0, 2.0.0
>
>         Attachments: OPENJPA-1550-13x-testcase.patch.txt, OPENJPA-1550-13x-v2.diff.txt,
OPENJPA-1550-13x.patch, OPENJPA-1550-trunk-testcase.patch.txt, OPENJPA-1550-trunk.patch, OPENJPA-1550.diff.txt,
OPENJPA-1550v2.diff.txt
>
>
> Exception reporting is different depending on the value of batchLimit.  To describe and
demonstration this problem, lets take the following Entitiy:
> @Entity
> public class Ent1 {
>     @Id
>     private int pk;    
>     private String name;
> .....
> }
> As a test, lets assume that we have an Ent1 with pk=200 already defined in the DB and
our test will attempt to create and persist another Ent1 with pk=200 (i.e. a duplicate key).
 In so doing we get the following exception as indicated by the batchLimit settings:
> batchLimit=0 or batchLimit=1
> Caused by: <openjpa-1.2.2-SNAPSHOT-r422266:889769M nonfatal store error> org.apache.openjpa.persistence.EntityExistsException:
The statement was aborted because it would have caused a duplicate key value in a unique or
primary key constraint or unique index identified by 'SQL100301111328870' defined on 'ENT1'.
{prepstmnt 33038075 INSERT INTO Ent1 (pk, name) VALUES (?, ?) [params=(int) 200, (String)
twohundred]} [code=20000, state=23505]
> FailedObject: siemens75007.Ent1@19d0e0b
> when batchLimit=-1 or >1
> Caused by: <openjpa-1.2.2-SNAPSHOT-r422266:889769M nonfatal store error> org.apache.openjpa.persistence.EntityExistsException:
The statement was aborted because it would have caused a duplicate key value in a unique or
primary key constraint or unique index identified by 'SQL100301111328870' defined on 'ENT1'.
> FailedObject: prepstmnt 33038075 INSERT INTO Ent1 (pk, name) VALUES (?, ?) [org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement]
> Notice that when batchLimit=[0,1], the exception lists the prepared statement used along
with the params which caused the failure, as well as the 'FailedObject'.  Furthermore, calling
'getFailedObject' on the resultant exception will give the caller the entity which caused
the failure.  In contrast, when batchLimit=-1 or a value greater than 1, we can see that the
exception message is missing the prepared statement info, however, it is presented in the
'FailedObject'.  The params are also missing from the prepared statement.  A call to 'getFailedObject'
on the resultant exception will NOT give the caller the entity which caused the exception.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message