You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by David Blevins <da...@visi.com> on 2011/02/11 00:37:41 UTC

Fwd: Newbie troubles attempting CMP entity insert

A user had reported this to us, forwarding it over on their behalf.  Do with it as you will :)

Here's the thread if you want the full stack trace:

 http://openejb.979440.n4.nabble.com/Newbie-troubles-attempting-CMP-entity-insert-tp3297911p3300418.html

Begin forwarded message:

> From: tjsaker <ti...@gmail.com>
> Date: February 10, 2011 2:33:40 PM PST
> To: dev@openejb.apache.org
> Subject: Re: Newbie troubles attempting CMP entity insert
> Reply-To: dev@openejb.apache.org
> 
> 
[...]
> 2) The fact that OpenEjb reports the issue incorrectly.  Here is the section
> of code in class org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl
> that handles the insert:
> 
>    protected void flushAndUpdate(RowImpl row) throws SQLException {
>        // prepare statement
>        String sql = row.getSQL(_dict);
>        PreparedStatement stmnt = prepareStatement(sql);
> 
>        // setup parameters and execute statement
>        if (stmnt != null)
>            row.flush(stmnt, _dict, _store);
>        try {
>            int count = executeUpdate(stmnt, sql, row);
>            if (count != 1) {
>                Object failed = row.getFailedObject();
>                if (failed != null)
>                    _exceptions.add(new OptimisticException(failed));
>                else if (row.getAction() == Row.ACTION_INSERT)
>        .
>        .
>        .
> 
> The problem is actually in the constructor OptimisticException(Object),
> where it defaults the error message to "opt-lock":
> 
>    public OptimisticException(Object failed) {
>        this(_loc.get("opt-lock", Exceptions.toString(failed)));
>        setFailedObject(failed);
>    }


Re: Newbie troubles attempting CMP entity insert

Posted by Heath Thomann <jp...@gmail.com>.
For folks that look at this, I don't think we have an issue here.  That is,
if I understand the user's explaination, they think we are reporting an
exception incorrectly.  However, if I read the full description of the issue
which is here:


http://openejb.979440.n4.nabble.com/Newbie-troubles-attempting-CMP-entity-insert-tp3297911p3300418.html

The user states the following:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1) The actual cause, which ended up being a MySQL bug with the version I was
running ( go figure the odds on that one :| ).  I upgraded and that solved
things.  The JDBC insert was returning a count of 7810893, *every time*.
 See here:

    http://bugs.mysql.com/bug.php?id=29692

2) The fact that OpenEjb reports the issue incorrectly.  Here is the section
of code in class org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl
that handles the insert:

    protected void flushAndUpdate(RowImpl row) throws SQLException {
        // prepare statement
        String sql = row.getSQL(_dict);
        PreparedStatement stmnt = prepareStatement(sql);

        // setup parameters and execute statement
        if (stmnt != null)
            row.flush(stmnt, _dict, _store);
        try {
            *int count = executeUpdate(stmnt, sql, row);
            if (count != 1) {
                Object failed = row.getFailedObject();
                if (failed != null)
                    _exceptions.add(new OptimisticException(failed));*
                else if (row.getAction() == Row.ACTION_INSERT)
        .
        .
        .

The problem is actually in the constructor OptimisticException(Object),
where it defaults the error message to "opt-lock":

    public OptimisticException(Object failed) {
        this(_loc.get(*"opt-lock"*, Exceptions.toString(failed)));
        setFailedObject(failed);
    }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


I think the important bit is in (1) above, that is, the bug in the JDBC
driver where the wrong count is returned.  If an incorrect code is returned,
all downstream code is susceptible and I don't see how we can try to cover a
case where some other code (JDBC driver in this case) returns the wrong
thing. The OptimisticException is a side effect of the wrong return count,
and I don't see how we could detect this.  I have a local test which
replicates a similar bug in an Oracle JDBC driver where the wrong count is
returned, thus leading to an OptimisticException.....if I move to a
different driver all works fine.  In the normal case, the count allows us to
determine if an optimistic update has occurred.

Thanks,

Heath


On Thu, Feb 10, 2011 at 4:37 PM, David Blevins <da...@visi.com>wrote:

> A user had reported this to us, forwarding it over on their behalf.  Do
> with it as you will :)
>
> Here's the thread if you want the full stack trace:
>
>
> http://openejb.979440.n4.nabble.com/Newbie-troubles-attempting-CMP-entity-insert-tp3297911p3300418.html
>
> Begin forwarded message:
>
> > From: tjsaker <ti...@gmail.com>
> > Date: February 10, 2011 2:33:40 PM PST
> > To: dev@openejb.apache.org
> > Subject: Re: Newbie troubles attempting CMP entity insert
> > Reply-To: dev@openejb.apache.org
> >
> >
> [...]
> > 2) The fact that OpenEjb reports the issue incorrectly.  Here is the
> section
> > of code in class
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl
> > that handles the insert:
> >
> >    protected void flushAndUpdate(RowImpl row) throws SQLException {
> >        // prepare statement
> >        String sql = row.getSQL(_dict);
> >        PreparedStatement stmnt = prepareStatement(sql);
> >
> >        // setup parameters and execute statement
> >        if (stmnt != null)
> >            row.flush(stmnt, _dict, _store);
> >        try {
> >            int count = executeUpdate(stmnt, sql, row);
> >            if (count != 1) {
> >                Object failed = row.getFailedObject();
> >                if (failed != null)
> >                    _exceptions.add(new OptimisticException(failed));
> >                else if (row.getAction() == Row.ACTION_INSERT)
> >        .
> >        .
> >        .
> >
> > The problem is actually in the constructor OptimisticException(Object),
> > where it defaults the error message to "opt-lock":
> >
> >    public OptimisticException(Object failed) {
> >        this(_loc.get("opt-lock", Exceptions.toString(failed)));
> >        setFailedObject(failed);
> >    }
>
>