MDB вставляет повторяющиеся записи

1

Я использую JBOSS 5.1.2 MDB для использования сообщений сущностей, помещенных в очередь. Производитель сообщений может создавать несколько сообщений для одного и того же объекта. Эти объекты сообщений определяются их номером сущности. (msg_entity_no) Я должен вставить запись в существующую таблицу сущностей, только если сущность не существует иначе я должен обновить существующую запись. Существующая таблица сущностей не является уникальной для этого номера сущности, так как она имеет другой внутренний ключ. т.е. он содержит дубликат msg_entity_no

Проблема, с которой я сталкиваюсь, заключается в том, что при создании нескольких сообщений несколько экземпляров запроса MDB для существования в таблице сущностей одновременно. В то время это не существует для любого экземпляра, и процесс затем вставляет для обоих сообщений. В отличие от одной вставки для несуществующего объекта, а затем обновления записи для последующих сообщений.

Я хочу уйти от использования аннотации @ActivationConfigProperty (propertyName = "maxSession", propertyValue = "1") и развертывания в папке deploy-hasingleton, которая разрешает только один экземпляр MDB, поскольку это не масштабируется.

  • 1
    Вы работаете в кластерной среде?
  • 0
    Как определяются ваши первичные ключи?
Показать ещё 3 комментария
Теги:
queue
jboss5.x
ejb-3.0

1 ответ

0
Лучший ответ

Условие, которое вы получаете, связано с DUPLICATE или SAME DATA содержащимся в сообщениях, которые помещаются в очередь в течение короткой последовательности. Для этого есть несколько решений.

1) DEQUEUE На одном экземпляре JBOSS с одним mdb. Это означает, что у вас будет один MDB, работающий на одном сервере JBOSS в кластере, сообщения будут по существу обрабатываться последовательно.

2) Создайте механизм блокировки, при котором вы создадите таблицу, напишите содержимое сообщения в эту таблицу с помощью PRIMARY KEY и содержимого сообщения. Затем вы отфильтровываете или создаете порядок обработки данных, которые должны обрабатываться на основе содержимого. Это замедлит время выполнения, но у вас будет лучший аудит для ваших данных. По сути, у вас есть две ASYNC процесса ASYNC. Один для заполнения данных из QUEUE а другой - для PROCESS данных. Вы могли бы сделать это через минуту.

3) Некоторые реализации QUEUE, такие как ORACLE AQ, имеют dequeue condition которое может быть установлено. Сообщения в очереди оцениваются с условием, и сообщения, которые удовлетворяют данному условию, возвращаются. TIBCO имеет стратегии блокировки, которые защищают поток выполнения, когда несколько потоков в агенте.

Ссылки http://tech.chococloud.com/archives/2152

Не понимая бизнес-процесс, я предлагаю вам попробовать предотвратить сообщения "DUPLICATE" из источника.

Поделиться
  • 0
    спасибо ... вариант 2 звучит жизнеспособно для моих целей. И вы правы в том, что источник загрязнен, и вы сначала попытаетесь устранить его там.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню