response.sendRedirect(url)

Надо логики? Смысл в том, что браузер при обновлении страницы повторяет последний запрос, в том числе и POST. Причем еще и с теми же параметрами, отсюда дублирование данных. То есть после обработки поста надо сделать так, чтобы последним запросом было что-то еще, то есть GET, например. Для этого и отправляется редирект.
forward же просто запускает обработчика для нового адреса в рамках исходного запроса. А значит проблема с повторным постом сохраняется.
Вывод - меняем в коде из 1 поста форвард на редирект и дублирование данных при обновлении страниц прекратится.

Пишу с телефона, так что до вечера примера кода от меня не будет по причине не вполне удобного ввода. Общая мысль в том, что форвард это продолжение обработки одного и того же запроса, потому и доступ к функции идет через реквест. Редирект же это отправка HTTP кода 304 (или какого еще из 300-х), с сообщением что запрошенный ресурс надо искать в другом месте. То есть если код из первого поста работает, замена форварда на редирект в тот же адрес куда был форвард должна оставить его как минимум не менее рабочим.
Примечание - форвард идет по путям внутри приложения (например, так можно сослаться на файл, заныканный в WEB-INF), а редиректить надо на полноценный урл, например request.contextroot() + путь на который форвардили.
Примечание 2 - все вышенаписанное относится к случаю когда в doPost происходит обработка данных, а не вывод еще и результатов обработки. Если обработчик поста получает данные и выплевывает результат обработки - остается дергать этот сервлет через ajax. Или думать как разделить получение данных и возврат результата обработки.

Чуть было не предложил редиректить на result.jsp, но все-таки маловато данных для такого. Сначала вопросы:
1. В приложении 2 страницы index и result?
2. Парсеры xml сторонние? (Смысл вопроса - оценить возможность правки их обработчиков если что)
3. В какой момент и как именно выводится результат? Меня беспокоит мысль что объект с результатом могут просто запихивать в атрибут реквеста и в таком виде он может попадать к result.jsp.

Ничего страшного, в принципе, только грабли с дублированием POST-ов.
Решения по возрастанию затрат времени.
1. Большие красные буквы "СТРАНИЦУ НЕ ОБНОВЛЯТЬ"
2. На каждый запрос создавать парсер заново, никаких кешей и синглтонов - это если те не пытаются хранить свое состояние еще где-то.
3. Посмотреть в сторону ajax.
4. Прочие методы от костылестроения до переработки приложения.

Правильно ли я понял, что только один парсер от запроса к запросу не обнуляет данные? И он их не обнуляет только при обновлении страницы или еще и для нескольких разных xml-ей обработанных подряд выдает их все скопом? Я не против синглтонов вообще, но вот сам проблемный парсер можно (и, судя по поведению, нужно) пересоздавать на каждый запрос, хотя бы и в методе синглтона.

По поводу сделать с реквестом - результат можно класть в doPost() в бин (когда command.execute отработает вынуть из реквеста атрибут с готовым результатом и засунуть в бин), выдавать редирект на result.jsp, а в result.jsp (или сопутствующем сервлете) уже результат выводить. Это не исправит косячного парсера, но избавит от напоминания браузера "послать заново данные формы?".

P.S. Если используются стандартные библиотеки, то скорее виноват не парсер, а обвязка, его вызывающая, может там забыли подчистить данные между обращениями.