Кэшировать значения в Java EE

Я создаю простое приложение делегирования сообщений. Сообщения отправляются на обоих концах через JMS. Я использую MDB для обработки входящих сообщений, их преобразования и отправки в целевую очередь. К сожалению, одни и те же сообщения могут быть отправлены во входящую очередь более одного раза, но пересылка дубликатов не допускается.

Так каков наилучший способ добиться этого?

Поскольку во входящей очереди может прослушиваться несколько MDB, мне нужен один кеш, где я могу хранить уникальные uuid сообщений входящих сообщений в течение как минимум часа. Как получить доступ к этому кешу? Через одноэлементный/статический класс (я использую Java EE 5 и, следовательно, не имею одноэлементной аннотации)?

Кроме того, я думаю, что все операции должны быть синхронизированы, верно? Это сильно вредит производительности?


person Leikingo    schedule 14.07.2011    source источник


Ответы (1)


@Ingo: у тебя все в порядке с решением для базы данных. Для этого вы можете использовать полноценный сервер БД или простое решение apache derby. Если это так, у вас может быть простая таблица, в которой вы можете хранить уникальный UId сообщения и проверять его на уникальность... это решение будет иметь следующие преимущества:

  1. Простой код
  2. Нет необходимости в кэше с привязкой ко времени (1 час). Вы можете проверять уникальность сообщения навсегда.
  3. Постоянная запись входящих сообщений.
  4. Нет необходимости в дорогостоящей синхронизации, вы можете положиться на уровень изоляции БД для согласованности.
  5. централизованное решение для возможного множества развертываний приложения.
person ag112    schedule 15.07.2011
comment
Привет и спасибо за быстрый ответ. Я согласен с большинством ваших преимуществ, но я думаю, что использование решения db немного превышает простое кэширование некоторых строк. Кроме того, мне все равно понадобится дополнительная работа для истечения срока действия ключей и очистки таблицы, потому что мне не нужен длительный протокол входящих сообщений. По поводу синхронизации: я думаю, что БД просто скрывает это. Но тем не менее, я предложу ваше предложение. После небольшого чтения, как насчет ehcache? - person Leikingo; 15.07.2011