Как Spring знает, что нужно обновить начальный контекст, если один член кластера выходит из строя

Я использую портлет Spring MVC в качестве внешнего интерфейса и подключаюсь к некоторому удаленному EJB, работающему на WAS. Теперь в моем файле конфигурации для портлета, где я указываю URL-адрес поиска удаленного EJB, я указал URL-адреса как кластер, поскольку EJB развернут в кластерной WAS. Таким образом, URL-адрес выглядит так: iiop://server1:port,iiop://server2:port.

Теперь, чтобы сэкономить ресурсы, spring mvc кэширует начальный контекст. Теперь я замечаю, что spring всегда может установить соединение с удаленным ejb, пока один из серверов работает.

Это сбивает меня с толку, поскольку кластер разрешается (из-за отсутствия лучшего слова) во время поиска начального контекста, и после этого, если член кластера выходит из строя, должно быть исключение соединения. Так как же Spring узнает, когда он должен автоматически обновить свой первоначальный контекст, потому что старый контекст устарел?


spring-mvc caching lookup ejb-3.0 remoteobject
person Victor    schedule 13.08.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я обнаружил, что в файле applicationContext.xml есть объявление:

<jee:remote-slsb id="remoteService" jndi-name="com.business.ejb.ServiceSLRemote" business-interface="com.business.ejb.ServiceSLRemote" cache-home="true" lookup-home-on-startup="false" resource-ref="false" refresh-home-on-connect-failure="true">
<jee:environment>
java.naming.factory.initial=${JAVA.NAMING.FACTORY.INITIAL}
java.naming.provider.url=${JAVA.NAMING.PROVIDER.URL}
</jee:environment>
</jee:remote-slsb>

Именно refresh-home-on-connect-failure="true" сообщает контейнеру Spring, что если исходный контекст устарел, он должен обновить соединение. Вот как это может работать, пока активен один член кластера.

person Victor    schedule 13.08.2012