stdio Именно, любой CMP Entity Bean, который он геренирует при установке приложения, будучи кэширован и хотя бы один раз обновлен в процессе своей "жизни" в кэше, при всех последующих обращениях к нему на чтение (доступ к атрибутам) до конца "жизни" в кэше исполняет ejbStore(), несмотря на то, что при последнем обновлении этот метод был уже вызван и обновления сохранены в БД
и ты считаешь, что это правильно


Я не утверждаю, что это правильно. Я утверждаю, что это неправильно. Если состояние бина было сохранено в БД после последнего обновления, то нет никакой нужды снова и снова его сохранять в БД при каждом последующем обращени к бину в других сессиях. Это противоречит концепции EJB в принципе.

ПС. Это не ответ stdio, это комментарий тем, кому интересно.

stdioи также указываешь, что
1. Если есть основания ожидать, что Entity Bean может рассинхронизироваться вследствие обновления записи вне EJB контейнера, есть возможность при установке (deployment) указать exclusive-write-access="true".

2. Но даже при этом бин будет ПЕРЕЧИТЫВАТЬСЯ, а не ОБНОВЛЯТЬ запись в БД. Это две большие разницы, как известно. В том числе и с точки зрения блокировок в БД.
и тут ты считаешь, что это неправильно. (кстати, мне не понятно, про блокировки. В Оракле чтение является неблокирующим)


Я не считаю, что это неправильно. Это как раз правильно, если данные в БД могут обновляться помимо EJB контейнера. И это безвредно именно по указанной Вами причине.

stdioДля начала предоставлю решение проблемы несчастного программиста. Ему надо было указать, что компонент является не только exclusive-write-access="true", но locking-mode="read-only". Только в этом случае чтение значений атрибутов не будет приводить к чтению из БД.

Значение exclusive-write-access="true" может использоваться только в случае, если у нас locking-mode="read-only" (читаем документацию), иначе мы сталкиваемся с проблемами параллельного доступа к компонету. Советую не читать спецификацию EJB, а просто подумать над ситуациями, когда четыре клиента начинают работать с одним и тем же компонентом одновременно.

Первый - только читает значения полей.
Второй - постоянно их модифицирует.
Третий - постоянно их модифицирует.
Четвёртый - постоянно их модифицирует.

И при этом рекомендую не забывать про транзакции.

Желаю счастливых фантазий. гыгыгы.

Я Вам про Фому, а Вы про Ерему. Жаль. Вы, похоже, так и не уловили, что я говорил о методе ejbStore(), а этот метод как раз сохраняет состояние бина в БД, а не читает его. Впрочем, желаю стебаться дальше.

Нам было тогда не до стеба. Мы сами рекомендовали Orion Server клиенту (не я лично, но компания). Клиент не хотел open source, хотел что-нибудь за деньги, но не сильно дорого. Поэтому пришлось выкручиваться. Вот после этого (да и до этого) я практически никогда не рекомендовал заказчиам (когда они спрашивали) коммерческие продукты, если была возможность использовать open source (а а такая возможность на платформе J2EE есть всегда).

stdioА раз они необоснованны, то все прочие выводы, которые сделал, отталкиваясь от них - являются ложными.

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

stdio: предлагаю закончить на этом. Если не терпится сказать последнее слово, ради Бога. Но больше не отвечаю.