Это аргумент аннотации @SequenceGenerator. Так что же он означает?
Когда мы пишем например
То это означает, что вызывается в базе(например в PostgreSQL) следующий запрос:
Тоесть создается сиквенс, который начинается с одного, и инкрементируется по 10.
Мы имеем один ентити менеджер, который управляет транзакциями нашего класса(у которого один из аргументов тот, что мы чуть выше описали), при первой транзакции, которой нужно значение сиквенса, создается этот сиквенс и заносится поточное значение в индексую колонку таблицы-виновницы этой транзакции. Потом со следующими транзациями JPA провайдер не обращается к базе за сиквенсом а сам еще 9-ть раз инкрементит значение, после чего опять выбирает из базы ITEM_ID_SEQ.NEXTVAL и снова не беспокоит ее 10 шагов инкриментирования.
Если же другой энтити менеджер обратиться к этому сиквенсу, то ему предоставится значение следующего шага, который отслеживает RDBMS, в нашем случае, если первый еще не израсходовал первую совю десятку, это будет 11.
При этом не факт, что первый энтити менеджер израсходует весь свой выделенный диапазон -- так получаются гаспы(пробелы) в значениях ключей. Чтобы пробелов не было allocationSize должен равняться 1. Но тут мы платим производительностью, ведь с каждым инкрементированием мы должны обращаться в базу.
Когда мы пишем например
@Id @Column(name = "ITEM_ID") @GeneratedValue(strategy = GenerationType.SEQUENCE, generator="ItemIdSeqGenerator") @SequenceGenerator(name="ItemIdSeqGenerator", sequenceName="ITEM_ID_SEQ", allocationSize=10) private long itemId;
То это означает, что вызывается в базе(например в PostgreSQL) следующий запрос:
CREATE SEQUENCE ITEM_ID_SEQ START WITH 1 INCREMENT BY 10;
Тоесть создается сиквенс, который начинается с одного, и инкрементируется по 10.
Мы имеем один ентити менеджер, который управляет транзакциями нашего класса(у которого один из аргументов тот, что мы чуть выше описали), при первой транзакции, которой нужно значение сиквенса, создается этот сиквенс и заносится поточное значение в индексую колонку таблицы-виновницы этой транзакции. Потом со следующими транзациями JPA провайдер не обращается к базе за сиквенсом а сам еще 9-ть раз инкрементит значение, после чего опять выбирает из базы ITEM_ID_SEQ.NEXTVAL и снова не беспокоит ее 10 шагов инкриментирования.
Если же другой энтити менеджер обратиться к этому сиквенсу, то ему предоставится значение следующего шага, который отслеживает RDBMS, в нашем случае, если первый еще не израсходовал первую совю десятку, это будет 11.
При этом не факт, что первый энтити менеджер израсходует весь свой выделенный диапазон -- так получаются гаспы(пробелы) в значениях ключей. Чтобы пробелов не было allocationSize должен равняться 1. Но тут мы платим производительностью, ведь с каждым инкрементированием мы должны обращаться в базу.
Комментариев нет:
Отправить комментарий