On Feb 10, 2011, at 2:33 PM, tjsaker wrote: > > Thanks David, I figured things out though.
Excellent! Definitely still check out the sample I mentioned for the embedded unit testing setup. You'll love it. Even just watch the video to see how quick it is. A big time saver. > This issue has two facets: > > 1) The actual cause, which ended up being a MySQL bug with the version I was > running ( go figure the odds on that one :| ). The JDBC insert was > returning a count of 7810893, *every time*. See here: > > http://bugs.mysql.com/bug.php?id=29692 Wow! > 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'll forward this over to OpenJPA to make sure it's on their radar. -David
