тогда конкретная имплементация будет отвечать за ту сущность, например UserVersionImpl implements Version<User>

Это уже какой-то Versioned

🤷‍♂️ тут сложно делать предположения, непонятна вся логика

возможно такое решение подойдет, возможно нет

Подумаю, интересный вариант

во всяком случае если нужно решить вопрос "как уйти от каста" - данное решение эту проблему закрывает, вопрос лишь в том допустима ли такая логика

Как насчёт такого?
class VersionImpl implements Version<VersionImpl> {

 @Override
 public int compareTo(VersionImpl o) {
   return 0;
 }
}

interface Version<T extends Version<T>> extends Comparable<T> {}

А чтобы использовать нужно будет тогда делать что-то в духе:

class ItemWithVersion<T extends Version<T>> {

private T version;

}

В общем буду пробовать варианты, благо предложили достаточно

Спасибо

Это лучше, чем бесконечный цикл в смысле (while (true) { ... Thread.sleep(); }), т.к. будет использовать поток из пула потоков, вместо блокировки потока.

Я понял, спасибо

How can I convert a jna PointerByReference into Array[Pointer] ?

I tried to declare it inside the callback but I get an IllegalArgumentException, it works with PointerByReference but I want to access it like an array:
https://github.com/metacall/core/blob/51a7b042ea9b81d458e3d251852eee313aae2530/source/ports/scala_port/src/test/scala/MetaCallSpec.scala#L228

The source is in Scala but I'm ok with Java.

Вот есть такой вопросик по hibernate + spring-data.
Я две одинаковые транзакции в разных потоках и в них делаю findById.
Потом делаю тоже самое, но с PESSIMISTIC_WRITE-локом (т.е. select for update). Одна транзакция выигрывает, вторая зависает на локе.
Далее в первой транзакции делаю update и commit транзакции.
Тут лок отпускается и во второй транзакции получаю объект, но со старым значением (до update), потому что entity уже есть в persistence context. Делаю update и теряю предыдущий update.

Это ожидаемое поведение? Можно ли как-то настроить hibernate, чтобы второй select for update обновлял мою entity?

А не проще ли использовать уровень изоляции Repeatable Read. Он не даст другой транзакции прочитать, если в первой было обновление.

Да, это вариант, но тогда придётся повторять транзакции в таких случаях, а для этого не хочется городить логику.

Вот, запилил минимальный код
https://gist.github.com/genuss/4bbb5c1fa4e0ae297e1abe3bb1229763

Всё ломает первый findById. Если его убрать, то всё будет работать, как и планировалось.
Думаю, что в реальном коде я его просто уберу у себя, это должно быть не очень сложно, но интересно, почему так работает?

Дело в том, что с явными блокировками можно нарваться на эскалацию. Например, MSSQL любит заблокировать не только определенные записи, но и всю таблицу, потому что ему так проще

Это плохой путь

Это правда, явные блокировки могут быть так реализованы, что будут блокировать лишнее. Тут ещё и с индексами могут быть проблемы, если будут insert/delete

Достаточно "хрупкий" код получается, кто то другой залезет и сломает - сделайте лучше на оптимистических блокировках - повторите проигравшую транзакцию ничего страшного