Db2 forupdate fix

[nPraml]

Hello Rob,

In our application we assume that the forUpdate() query locks the selected rows (that read access from another thread is no longer possible). It works on MariaDb and SqlServer, but not on Db2.

The DB2 documentation states that the rows are locked but are not protected against write access: https://www.ibm.com/docs/en/db2/11.5?topic=statement-update-clause

We found out that if you add an orderBy("id") to the query, the locking also works under DB2. In our opinion it is just a workaround and not the solution. (And we do not understand why)

We found another way for DB2 forUpdate() to lock the rows: with rs use and keep update locks

Can you please look at the PullRequest and give us feedback?

Best regards
Noemi

[rPraml]

Did we use "forUpdate" in a wrong way?
We used it for synchronizing two or more application-instances when accessing a certain piece of code. In the special use case we have a shared NFS directory where only one instance should access this directory.

This was done with a

try(Transaction txn = DB.beginTransaction()) {
   List configs = DB.find(DirectoryScanConfig).where(...).forUpdate().findList(); // other thread will block here
   // scan the directory in the config(s)
}

Now we found out, that this might be the wrong way. Reasons:

• it does not work in DB2 as we expected. And we cannot explain, why it would work with order by id - does DB2 lock the index?
• BTW: it also does not work on H2 as there is a default lock timeout of 2s. So an other thread will block only for this time (see test)

Nevertheless, we need something to do a synchronization over DB.
@rbygrave - if we misunderstand the purpose of forUpdate, what do you think, if we extend the API with a query.lockRows() or optionally query.lockRows(timeout) that can be used to implement this kind of locking. It can be implemented with for update by default, maybe with an infinity timeout on H2 or with rs use and keep lock on DB2

FYI: This locking is also used on DbMigration for some platforms

[rPraml]

here we check, if the second thread blocks, while the first thread locks the data for at least 3000 ms.

[rPraml]

rs = read stablility
Maybe relevant doc links:
https://www.ibm.com/docs/en/db2/11.5?topic=statement-update-clause
https://www.ibm.com/docs/en/db2/11.5?topic=statement-isolation-clause
https://www.ibm.com/docs/en/db2/11.5?topic=issues-isolation-levels
https://www.ibm.com/docs/en/db2/11.5?topic=statement-lock-request-clause

[rbygrave]

Did we use "forUpdate" in a wrong way?

No, you used it in the way I would expect.

it does not work in DB2 as we expected

Yes, DB2 is taking its own approach/syntax here imo (which I think is confusing).

This locking is also used on DbMigration for some platforms

Not for DB2 though, DB2 is using "LogicalLocking" for DbMigration.

So yes, I'm happy with this PR.