Spring JPA путаница в хранилище путаницы

Question

У меня есть некоторая путаница в отношении того, как работает блокировка репозитория Spring JPA, и мне нужно кое-что прояснить.

Итак, у меня есть служба загрузки Spring, в которой я использую hibernate для взаимодействия с базой данных. В одном из сервисов у меня есть такая сущность: -

    @Entity
    @Table(name="JUNIPER_SCH_CURRENT_JOB_DETAIL", schema="juniperx")
    public class JuniperSchCurrentJobDetail {

    private int currentJobSequence;

        ......

    @Id
    @GeneratedValue(strategy=GenerationType.SEQUENCE)
    @Column(name="CURRENT_JOB_SEQUENCE")
    public int getCurrentJobSequence() {
    return currentJobSequence;
    }
    public void setCurrentJobSequence(int currentJobSequence) {
    this.currentJobSequence = currentJobSequence;
    }
    .......

Теперь у меня есть хранилище, помеченное как @Repository и расширяющее JPARepository, как показано ниже:

   @Repository
   public interface JuniperSchCurrentJobDetailRepository extends 
   JpaRepository<JuniperSchCurrentJobDetail, String> {

   @Query
   public List<Object[]> findLastRunJobDetail(@Param("projectId") 
    String projectId);

Таким образом, путаница заключается в том, что один из моих коллег сказал мне не использовать @Repository и @Entity для этой таблицы, поскольку таблица, на которую ссылаются, имеет очень высокую частоту вставок и обновлений из другого приложения. А использование репозитория JPA заблокирует эту таблицу и вызовет проблему.

Итак, мой запрос: -

1) В этом микросервисе я использую только запросы на выборку в этой таблице, так же как и запрос на выборкутакже заблокировать эту таблицу?

2) Из того, что я прочитал, если я использую оптимистическую блокировку, она включит блокировку только при фиксации транзакции, но поскольку этот микросервис только читает данные, он все равно будет влиять на другие службы, которые выполняют вставки и обновления в этомтаблица?

3) Если блокирующая часть истинна, есть ли возможность остановить блокировку?

4) Я в порядке с чтением грязных данных в этом микросервисе, как и для заполнения панели мониторинга. который не в реальном времени, так что это нормально, чтобы продолжать использовать @repository или я должен изменить его на шаблон JDBC, чтобы избежать проблемы с блокировкой?

5) Будет ли аннотирование класса с помощью @NoRepositoryBean и создание справки репозитория только для чтения?

Answer 1

будет ли запрос на выборку также блокировать эту таблицу?

этот микросервис только читает данные, будет ли он влиять на другие службы, которые выполняют вставки и обновления в этой таблице?

Некоторые базы данных создают блокировки для таблиц при чтении из них.

Это, однако, полностью не зависит от JPA и сильно зависит от базы данных. Вам нужно изучить конкретную базу данных, которую вы используете, чтобы узнать, как она себя ведет.

Запись обычно создает блокировки, по крайней мере, для строки, которую вы пишете, но также и для строк, на которые ссылаются через внешние ключи,Некоторые базы данных могут блокировать больше строк, чем они на самом деле записывают.

Опять же, это верно, если вы используете JPA, JDBC или любой другой инструмент SQL по вашему выбору.

Из того, что я прочитал, если я использую оптимистическую блокировку, она включит блокировку только при фиксациитранзакция

Нет, оптимистическая блокировка не создаст никаких дополнительных (блокирующих) блокировок, кроме упомянутых выше. Однако может произойти сбой обновлений, когда между чтением и записью строки произошло другое обновление. На самом деле целью оптимистической блокировки является предотвращение потерянных обновлений без блокировки записей (и, возможно, чтения).

Итак, я не вижу, как JPA в конфигурации по умолчанию генерировал бы больше блокировок, чем при использовании чего-то более низкого уровнякак JdbcTemplate.