Hi Kai, Thanks for that info. Do you perhaps also have a client code sample that will help reproduce the issue? As I've mentioned before, our integration tests cover a variety of interaction patterns. Perhaps, we've missed something, though. Ideally, I'd like to know:
1. The DDL of a table that you generated, which produces the observed behaviour 2. The client code (exact sequence of queries, store() / update() calls, which don't work) That would help me look in the right spots... Best Regards, Lukas 2016-05-06 22:28 GMT+02:00 Kai Waldron <[email protected]>: > Hey Lukas, > > Sure, I think this is what you're asking for: > > SQLDialect dialect = SQLDialect.valueOf("POSTGRES_9_5"); // also > same behavior with 9_4 > > return new DefaultConfiguration() > .derive(connectionProvider) // DataSourceConnectionProvider > .derive(transactionProvider) // SpringTransactionProvider > .derive(executeListenerProvider) > // DefaultExecuteListenerProvider > .derive(dialect) > .derive(new > Settings().withExecuteWithOptimisticLocking(true)); > > Let me now if you need any other details. > > Cheers, > Kai > > On Fri, May 6, 2016 at 5:06 AM, Lukas Eder <[email protected]> wrote: > >> Hi Kai, >> >> Thank you very much for your detailed report. It may be that there's a >> combination of settings flags that we currently don't cover with our >> integration tests to produce this. We currently still get the >> expected DataChangedException in such a case. To be sure we're talking >> about the same thing, can you please provide me with the complete Settings >> configuration that you're using? >> >> Best Regards, >> Lukas >> >> 2016-05-05 19:02 GMT+02:00 Kai Waldron <[email protected]>: >> >>> Just upgraded from 3.7.3 to 3.8.0 and running into the following >>> situation using optimistic locking. Other version details: Java 8, >>> PostgreSQL 9.5.x >>> >>> We've got a DSLContext with a config that >>> has withExecuteWithOptimisticLocking set to true and we are using a >>> rec_version integer field on our table. For our test, we fetch two of the >>> same record (same primary key), then change a value on record1, perform an >>> update, then change a different value on record 2, perform an update. Under >>> 3.7.3 this works as expected -- the second update on record 2 fails with a >>> DataAccessException. Under 3.8.0, however, even though the second update >>> technically fails (no modification is made to the database, updated rows is >>> 0, etc) jOOQ does not throw a DataAccessException and in fact appears to >>> treat the update as successful. >>> >>> Tracing through it, here are a few more details on what is going on: >>> >>> When record update() is invoked the following new logic is performed >>> (UpdateRecordImpl): >>> >>> line 251, setReturningIfNeeded is called, which sets the returning value >>> to be table.id >>> line 252, int result = update.execute(); >>> line 253, checkIfChanged(result, version, timestamp); >>> >>> >>> If you trace the update.execute() call down, eventually you hit an >>> execute() method in AbstractDMLQuery: >>> >>> line 325 has this conditional: >>> >>> if (returning.isEmpty()) { >>> return super.execute(ctx, listener); >>> } >>> >>> Under jOOQ 3.7.3, returning is in fact empty, so return >>> super.execute(ctx, listener); is what is invoked here. >>> >>> But under 3.8.0 we hit the else case which sets result to 1: >>> >>> int result = 1; >>> >>> And then switches on the database type, for Posgres we have: >>> >>> case POSTGRES: { >>> listener.executeStart(ctx); >>> rs = ctx.statement().executeQuery(); >>> listener.executeEnd(ctx); >>> break; >>> } >>> >>> The statement has in fact been executed (and updated 0 rows), but result >>> is still 1, so if we jump back to UpdateRecordImpl: >>> >>> line 252, int result = update.execute(); // result is 1 here (even >>> though query didn't update anything..) >>> line 253, checkIfChanged(result, version, timestamp); >>> >>> The checkIfChanged() call is going to fail in this case (fail in that it >>> doesn't throw a DataAccessException.). >>> >>> Hopefully that is enough detail to understand the problem. Is this a >>> bug? It sure seems like it. But let me know if there is some configuration >>> issue or some misunderstanding on my part. >>> >>> Cheers, >>> Kai >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jOOQ User Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "jOOQ User Group" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/jooq-user/o8aoDuZmGeo/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
