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 <[email protected]>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 <[email protected]> > > Date: February 10, 2011 2:33:40 PM PST > > To: [email protected] > > Subject: Re: Newbie troubles attempting CMP entity insert > > Reply-To: [email protected] > > > > > [...] > > 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); > > } > >
