Здравствуйте, knst, Вы писали:

K>Дык о том и речь. Но вопрос остается открытым, как мэппер узнает о том что ни какой-то из имеющихся в его IdentityMap объектов не используется неи одной из активных транзакций и его можно удалить?
В случае оптимистической транзакции, никак. Он и не должен это знать.
Кэш — это отражение базы данных. В нем должны храниться только объекты зафиксированные транзакциями. Проверка на корректность производится при записи объектов. И если объект был при этом удален (в данном случае это будет комманда update для несуществующего объекта), то должен быть откат всей транзакции. На то это и оптимистическая транзакция.

Посмотри здесь, я кое-чего писал.
Re: Транзакции

Автор: GlebZ
Дата: 11.02.05

С уважением, Gleb.

Здравствуйте, knst, Вы писали:

A прежде всего, повторюсь, IdentityMap в отличие от кэша — это транзакционное свойство, и он принадлежит конкретной транзакции. То есть, при заказе, если данного объекта нет в IdentityMap — он запрашивается у кэша. Если оно есть у кэша, то он предоставляет копию объекта(это самый простой механизм, есть еще механизмы песс. блокировок). Кэш не должен предоставлять объект измененный другой транзакцией и еще незафиксированный. Если в кэше его нет, то объект считывается с БД в кэш(или напрямую).
При фиксировании транзакции, измененный объект должен быть заменен как в кэше так и в БД. В случае удаления, должен быть удален из кэша и из БД. При фиксировании транзакции, IdentityMap убивается (как и сама транзакция).

С уважением, Gleb.

K>Вот такая трабла
K>есть бизнесобъект. есть его мэппер на БД
K>логично сделать некий кэш чтоб лишний раз не тягать объекты из базы.
K>Читал тов. Фаулера, так у него пример для мэппера такой, что рано или
K>поздно вытягивает всю базу в память.
K>Вопрос в том как и когда выкидывать объекты из кэша мэппера?
K>Единственное, что я придумал это считать обращения к объектам в кэше
K>и ограничить кол-во объектов в кэше , и при попытке превысить это кол-во
K>выкидыват объект с наименьшим числом обращений (или можнет обращений в минуту)
K>Но это как-то криво — долго подбирать ограничение кол-ва придется, да и в целом не красиво...
Можно использовать алгоритм LRU(Least Recently Used).

С уважением,
bw.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Dr.Gigabit, Вы писали:

DG>>Я бы добавил еще и состояние объекта, т.е. если мы создали некий объект и заполнили его значениями из БД — у него, скажем статус Loaded.
DG>>Далее в зависимости от CRUD операции, выполняемой маппером с этим объектом, меняется и его статус.
DG>>Скажем при статусе Deleted, удаляем объект из IdentityMap

IT>А если у нас стоит лоад-балансер и отбъкт был изменён на соседнем сервере?

Хороший вопрос Но общий механизм все равно остается прежним?
Т.е при совершении CRUD операции мы обращаемся к IdentityMap. А там хранятся объекты вместе со своими состояниями.
Я предлагаю ввести состояния только по отношению к CRUD операциям.

А если я буду использовать пессиместическая блокировку. Тогда по идее кеш вообще не нужен?
Т.к. перед началом редактирования объекта его требуется заблокировать в БД, затем считать, чтобы получить самую свежую версию и после этого модифицировать. А то что лежит в кеше может быть уже далеко не последней версией.

Здравствуйте, shev, Вы писали:

S>А если я буду использовать пессиместическая блокировку. Тогда по идее кеш вообще не нужен?
S>Т.к. перед началом редактирования объекта его требуется заблокировать в БД, затем считать, чтобы получить самую свежую версию и после этого модифицировать. А то что лежит в кеше может быть уже далеко не последней версией.

А если объект очень большой? Его что так и тягать всякий раз из БД, даже если он не изменялся между обращениями?
Вовсе нет! При обнаружении объекта в кэше нужно всего-лишь проверять его актуальность (не изменился ли он в БД) и одновременно блокировать этот объект в БД. А далее не тянуть заново все его данные из БД, а использовать те, что уже есть в кэш.
Как проверять актуальность? Структура БД должна предусматривать храниение информации о времени последнего изменения.