Использование Hibernate для запроса IBM i не все данные возвращаются, если записи были добавлены с зеленого экрана

Question

У меня возникла проблема, когда данные, созданные на нашей IBM i через традиционное приложение зеленого экрана, не отражены веб-приложением I Я пишу. Похоже, что записи, которые я добавляю из веб-приложения, сразу доступны как для веб-приложения, так и для IBM i, но записи, созданные мной в IBM, я не сразу доступен для веб-приложения. Я думал, что это может быть проблема с кешем, но после перезагрузки моего веб-приложения запись все еще не существует. Я пробовал установку javax.persistence.cache.retrieveMode на BYPASS, и эта настройка отражается, когда мой менеджер объектов Hibernate создан, но данные, возвращенные из моего запроса, по-прежнему не имеют записи, добавленной через зеленый экран.

На этом этапе я не думаю, что это проблема с кешем. Итак, вот тестирование, которое я сделал до сих пор.

Файлы, с которыми я работаю, это WOHDR2 и WOJOBS, где WOHDR2 является файлом заголовка, а файл WOJOBS является файлом детали.

Вот что я испытал до сих пор.

Запись добавлена ​​в файл WOJOBS через веб-приложение и непосредственно связаны с WOHDR2 - Эти записи отражают поле идентификатора родительского WOHDR2 и видны как в веб-приложение, и зеленый экран.

Запись добавлена ​​в файл WOJOBS через зеленый приложение экрана без какой-либо ID ассоциации к WOHDR2, а именно: он находится в состоянии отложенного до тех пор, пока пользователь не присваивает его WOHDR2 позже - Эта запись видна через зеленый приложение экрана, но а не веб-приложение

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

запись добавлена ​​в файл WOHDR2 через веб-приложение или зеленого приложения экрана - Записи видны через веб-приложение и приложение для зеленого экрана одновременно

Answer 1

Есть несколько причин, по которым вы не увидите записи, которые вы ожидаете.

1. Вы не чтение/запись в тот же файл (таблица)
2. Вы работаете под уровнем изоляции были вы не видите незавершенные записи и записи, которые вы написали, не были совершены ,
3. Записи на самом деле еще не записаны в таблицу.
4. В вашем приложении SQL используется копия данных вместо данных в реальном времени.

Solutions

1. При использовании неподходящих ссылки, убедитесь, что оба приложения решения в тот же файл. Предполагая, что соглашение об именах SYS, убедитесь, что оба приложения используют один и тот же список библиотек.
2. См isolation levels
3. Если вы используете программу RPG писать записи из зеленого экрана, нужно учитывать, что по умолчанию, RPG компилятор буфера записи, когда файл открыт только для вывода. Это также известно как «блокировка записи».Записи не будут отправляться в СУБД до тех пор, пока буфер не заполнит и/или файл не будет закрыт. Вы часто увидите FRCRATION (1), установленный через CHGPF или OVRDBF, чтобы обойти эту проблему. Но это плохая практика. Лучшей практикой является использование операционного кода Force End of Data (FEOD) с расширителем N, FEOD(N) mytable; в вашей программе RPGLE перед возвратом из нее. Это приведет к сбросу буферизованного вывода RPGLE в СУБД.
4. если ваш SQL открывает курсор до того, как приложение RPG добавит данные, возможно, значение по умолчанию позволяет копировать данные (ALWCPYDTA) = * ДА означает, что ваше веб-приложение работает со устаревшими данными. Вы можете управлять этим на уровне соединения или с помощью инструкции SET OPTION.

Следует отметить, что RPG не создает буфер, если есть уникальный ключ, определенный над таблицей, на которую записывается; иначе СУБД не сможет обеспечить уникальность. FRCRATIO (1) оставлен с обратной стороны до ведения журнала и контроля обязательств ... он позволил вам принудительно записывать записи не только в СУБД, но и все на диск. Включение этого сегодня - отличный способ замедлить ваше приложение.