Это не то, что делает JavaRebel. JavaRebel (согласно описанию) выполняет горячую замену классов в памяти. Это неприемлемо в случае существующих подключений к системе, поскольку обновленные классы могут нарушить логику клиента.
Однажды у компании, в которой я работал, была похожая проблема, и она была решена следующим образом:
- в качестве балансировщика нагрузки использовался интеллектуальный маршрутизатор
- новая версия была развернута на 50% узлов (нового) кластера
- новые соединения были доставлены строго к этим обновленным узлам, старые были сбалансированы между старыми узлами
- старые узлы были отключены (по одному, чтобы количество клиентов на узел не выходило за пределы)
- в то же время новая версия была развернута на автономных «старых» узлах, и они были представлены как новые узлы
- из-за EJB-кластеризации сеансы и компоненты были получены другими старыми узлами
- в конечном итоге (через несколько часов) остался только один старый узел с одним экземпляром старой версии, и все клиенты, использующие старую версию, были подключены к нему
- когда последний старый клиент был отключен, этот узел тоже был отключен
Теперь я не специалист по сетевым технологиям и не могу дать вам много подробностей (например, каково было оборудование маршрутизатора и тому подобное). Мое понимание этого может быть настроено довольно легко, за исключением того, что, если я правильно помню, нам пришлось настроить дополнительный домен Weblogic для развертывания новых версий приложения (в противном случае он будет конфликтовать со старым в именах JNDI).
Надеюсь, это поможет.
P.S. Ichorus предоставил комментарий о том, что приложение развернуто на клиентских серверах. Так что трюк с роутером может оказаться неосуществимым. Сейчас я вижу только одно жизнеспособное решение (сейчас 21:52, я могу пропустить некоторые вещи :)) -
- Разработка новой версии с "версионными" именами JNDI; например если компонент Customer был в ejb / Customer в версии 1, в версии 2 он был бы в ejb / Customer2
- Наличие в приложении бизнес-фасада со стабильным базовым интерфейсом (в стиле Factory), который, когда запрашивается компонент Customer, пытается найти имя JNDI с самой высокой версией (конечно, не каждый вызов может кэшировать для час или около того). Этот фасад может (и должен) быть развернут как отдельное приложение - и никогда или очень редко обновляться
- Теперь каждый новый клиент получит доступ к последнему развернутому приложению, и приложения не будут конфликтовать.
Этот подход требует тщательного планирования и тестирования, но должен работать ИМХО.
Недавно я изменил несколько приложений аналогичным образом, чтобы они могли сосуществовать в одном домене (до того, как они использовали одно и то же имя JNDI для разных источников данных).