авторКакая связь существует между уровнем изоляции транзакций, параметрами JPA Lock.READ / Lock.WRITE и версиями @Version(Оптимистическая блокировка)

Никакой.

Сначала, про Lock.READ / Lock.WRITE и @Version.
Это всего лишь два способа блокировки записи, первый(Lock.READ / Lock.WRITE) это прямое указание БД залочить запись, используется когда вы практически гарантированно уверенны, что одна и та же запись будет одновременно редактироваться разными пользователями, если один из пользователей открыл запись посредством Lock.READ / Lock.WRITE - второй пользователь просто тупо не сможет доступиться до этой записи, пока первый не снимет лок. Эта стратегия использования блокировок - называется пессимистичная блокировка, в самом названии содержится основной ее смысл - вы "пессимистично" предполагаете что доступ к записи на редактирование будет с высокой вероятностью перекрываться между разными пользователями. Это довольно дорогостоящая операция, и возможность масштабирования вашего приложения сильно уменьшается, таким образом практически ее стараются не использовать, а вместо нее используют оптимистическую блокировку.

@Version - это стратегия блокировки записи, которая по сути и не является блокировкой, в этом случае мы предполагаем что параллельного доступа к одной записи в большинстве случаев не будет. Как это все происходит на практике - в поле сущности добавляется аннотация @Version - которая автоинкременится при каждом последующем редактировании. Рассмотрим ситуацию, когда первый пользователь загрузил Book с id =2 и version =4, он меняет ее названия и пытается сохранить изменения - em.update(book). Что делает хибернейт, он создает запрос - update book where id=1 and version =4 set ...... Так вот, если с момента как пользователь загрузил книгу и моментом когда он ее пытается сохранить, никакой другой пользователь не проапдейтил книгу, то у нее останется версия=4, следовательно sql-запрос отработает нормально и данные сохранятся. Если же другой пользователь успел в этот момент проапдейтить книгу - то ее версия изменится на допустим =5, и sql запрос не отработает, хибернейт это дело определит и кинет соответствующий Exception - мол эта запись была отредактирована другим пользователем. В ваши обязанности входит перехватить это исключение и обработать в зависимости от use-case, вы можете либо заново вытащить этот book и заставить пользователя заново все вводить, либо как то смерджить и показать пользователю что изменилось и пусть он сам решает, либо тупо программно смерджить и попробовать сохранить снова, если есть уверенность что ничего не сломается. Таким образом получается что оптимистическая блокировка - это вовсе и не блокировка а просто предохранительное средство для того чтобы обнаружить конкурентные модификации в вашем приложении. Так как в большинстве случаев так и происходит, то цена оптимистической блокировки - практическа равна нулю, не считая лишнего поля в энтити. Таким образом ваше приложение совсем не теряет в возможности масштабирования.

Краткое резюме - пессимистическая блокировка используется при 1) большой вероятности коллизий 2) на очень больших формах, чтобы гарантированно не заставлять пользователя перезаполнять огромные формы(этот случай гораздо реже чем 1
В остальных случаях предпочтение отдается пессимистической блокировке.

Теперь об уровне изоляции транзакций. По большому счету этот параметр вам настраивать вряд ли придется. Дело в том, что у каждой БД свои поддерживаемые уровни изоляций, например, насколько я помню для Oracle - это REPETABLE_READ и SERIALIZABLE, если вы ничего специально не укажете хибернейту - он будет использовать дефолтный от БД. Следует сказать, что не все БД поддерживают все уровни изоляций, а что еще интереснее некоторые могут добавлять свои, так что этот параметр очень сильно зависит от используемой БД. На практике стараются использовать наименьший возможный уровень изоляции транзакций, который позволяет достичь целостности данных, в большинстве случаев это REPETABLE_READ и READ_COMMITTED.
Теоретически в хибернейт можно настроить через hibernate.connection.isolation в hibernate.cfg, но это не рекомендуемая практика. В моей практике случаев когда нужно было поменять дефолтный уровень на какой-то другой были единицы, и то это решалось в большинстве своем другими способами, чем изменение уровня изоляции. Теоретически вы можете сделать два пула для datasource с разными уровнями изоляций и в зависимости от задачи получить датасорс то из одного пула то из другого.

автора есть ли способ программно смоделировать одновременные транзакции чтобы что увидеть проблемы возникающие при разных уровнях изоляции?
Опять повторю, уровень изоляции - это конфигурационный параметр для каждого датасорса, теоретически вы можете настроить датасорс и так и так, и произвести SQL-запросы, но для этого надо читать мануалы по БД и JDBC

Чушь какая-то, точнее может оно то так и есть(про инкремент версии), но смешивание типов блокировок просто не имеет смысла