В этой статье хочу показать, что использование опции Passivate state на списках выбора (LOV), которая включено по умолчанию, не оправдана и может сказаться на производительности.
Схеме HR на Oracle XE
Подготовлю простой пример на таблице EMPLOYEES, к ней подключу два разных по типу списка выбора. На поле JOB_ID - selectOneChoice, а на поле DEPARTMENT_ID - inputComboboxListOfValues.
ApplicatioModule приложения настрою так что бы процесс passivation происходил на каждое обращение к странице (request) и данные состояния модуля записывались в файл.
Для это надо снять все галочки. А в свойствах настроить сохранение в файл:
Первый тест - passivation на LOV включена
форма ввода данных
Заходим на эту форму, меняем позицию, меняем данные :
LAST_NAME, JOB_ID, DEPARTMENT_ID
делаем submit данным и уходим с формы, смотрим файл passivation. Данные для самой записи EMPLOYEES
Сохранились именно измененные поля. Далее еще блок для EMPLOYEES, я так понимаю позиция (key)
А далее пойдет не маленький блок для LOV, особенно для типа inputComboboxListOfValues, видимо туда еще попадает информация для фильтров и др .
Она не зависит от объема данных LOV, но все же ее не мало.
Второй тест - passivation на LOV выключена
Так же заходим на страницу, модифицируем данные, submit, покидаем страницу, смотрим passivation файл.
В нем только модифицированные данные.
В общем то про это и сказано в документации
http://docs.oracle.com/cd/E28271_01/fusionapps.1111/e15524/adv_performance.htm#BBAGHJAH
58.2.3.3 Avoid Passivating Read-Only View Objects
There is performance overhead associated with passivation and activation. It is important to know of cases of where not to use this feature without impacting scalability and reliability. For example, there is no need to passivate LOV view objects and validator .....
Я просто решил все это проверить. При использовании большого количества LOV на формах излишнее сохранение - скажется на производительности.
Исходник
Схеме HR на Oracle XE
Подготовлю простой пример на таблице EMPLOYEES, к ней подключу два разных по типу списка выбора. На поле JOB_ID - selectOneChoice, а на поле DEPARTMENT_ID - inputComboboxListOfValues.
jbo.passivationstore file
jbo.tmpdir c:\Temp
jbo.tmpdir c:\Temp
Первый тест - passivation на LOV включена
форма ввода данных
LAST_NAME, JOB_ID, DEPARTMENT_ID
делаем submit данным и уходим с формы, смотрим файл passivation. Данные для самой записи EMPLOYEES
Сохранились именно измененные поля. Далее еще блок для EMPLOYEES, я так понимаю позиция (key)
Она не зависит от объема данных LOV, но все же ее не мало.
Второй тест - passivation на LOV выключена
Так же заходим на страницу, модифицируем данные, submit, покидаем страницу, смотрим passivation файл.
В нем только модифицированные данные.
В общем то про это и сказано в документации
http://docs.oracle.com/cd/E28271_01/fusionapps.1111/e15524/adv_performance.htm#BBAGHJAH
58.2.3.3 Avoid Passivating Read-Only View Objects
There is performance overhead associated with passivation and activation. It is important to know of cases of where not to use this feature without impacting scalability and reliability. For example, there is no need to passivate LOV view objects and validator .....
Я просто решил все это проверить. При использовании большого количества LOV на формах излишнее сохранение - скажется на производительности.
Исходник
Комментариев нет:
Отправить комментарий