Почему eclipselink потребляет весь размер размещения каждый раз при перезагрузке? - PullRequest
Новая
       16

Почему eclipselink потребляет весь размер размещения каждый раз при перезагрузке?

2 голосов
/ 28 октября 2010

Я только что заметил, что для идентификатора моей сущности eclipselink назначает идентификатор 1 + ранее назначенное в ОДНОЙ ЖЕ СЕССИИ (1), в отличие от таблицы элементов (2). Это противоречит ожиданиям моего приложения.

Какой самый простой способ сказать это сделать 2? 

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private int objId;

А вот что у меня в базе: 

ij> connect 'jdbc:derby:db';
ij> set schema memo;
0 Zeilen eingef?gt/aktualisiert/gel?scht
ij> select * from meaning;
OBJID      |LASTPUBLI&|USR_EMAIL                                                                                                                       
-------------------------------------------------------------------------------------------------------------------------------------------------------
1          |NULL      |NULL                                                                                                                            
2          |2010-10-27|NULL                                                                                                                            
51         |NULL      |NULL                                                                                                                            
101        |NULL      |NULL

1 Ответ

3 голосов
/ 28 октября 2010

При использовании стратегии GenerationType.AUTO с Derby EclipseLink по умолчанию использует стратегию таблицы генератора .

Затем, когда требуется генерация Id, EL будет предварительно распределять идентификаторы в соответствии сallocationSize (по умолчанию 50).Для этого он сначала обновит столбец, в котором хранится последнее сгенерированное значение, чтобы увеличить его на allocationSize: 

UPDATE SEQUENCE SET SEQ_COUNT = SEQ_COUNT + ? WHERE SEQ_NAME = ?
    bind => [50, SEQ_GEN]

, а затем прочитает новое значение: 

SELECT SEQ_COUNT FROM SEQUENCE WHERE SEQ_NAME = ?
    bind => [SEQ_GEN]

После этого EL предварительно выделяет пул идентификаторов, используя текущее значение - allocSize + 1 как «первое» и значение как «последнее»: 

local sequencing preallocation for SEQ_GEN: objects: 50 , first: 1, last: 50

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

Теперь, если вы перезапустите JVM, для EL просто не существует другого безопасного способа, кроме предварительного выделения нового пула идентификаторов ".потеря «тех из« предыдущего »диапазона, которые не использовались (например, multi-JVM и т. д.), что объясняет« скачок »от 2 до 51 в вашем примере.

Если вы хотите избежать этого,я бы предложил перейти на стратегию IDENTITY, которая поддерживается Derby (я не думаю, что было бы неплохо настроить генератор таблиц для использования allocationSize из 1).

Я не думаю, что настройка генератора таблицы для использованияВыделение 1 - хорошая идея.Почему бы и нет?

Из-за снижения производительности, если вам нужно читать из таблицы «последовательность» для каждой вставки.Но, с другой стороны, 1) это не может быть проблемой в вашем случае 2) Это единственная стратегия, которая позволяет получить действительно последовательные идентификаторы.

Если вам интересно, вы сможете настроить это глобально, используя элемент table-generator в XML-дескрипторе.

EL крайне не одобряет стратегию идентификации, к тому же она кажетсяявляются минами (потому что вы должны подождать, чтобы зафиксировать, прежде чем читать значение, что-то, что я мог бы где-то делать).

Ну, я не могу подтвердить для EL (я не буду проверять это прямо сейчас), но Hibernate выполняет немедленную вставку на persist, когда вы используете стратегию IDENTITY.Я думал, что EL будет вести себя так же.Но я могу ошибаться, это, похоже, не предписано спецификацией.

Ссылки

...