Spring context.refresh () и одновременный доступ - PullRequest
Новая
       24

Spring context.refresh () и одновременный доступ

1 голос
/ 02 октября 2011

Я планирую использовать Spring в качестве службы конфигурации для нашего корпоративного приложения.

Эта часть была хорошо задокументирована в весеннем справочном руководстве и других блогах.В основном, используя файл свойств и контекст: свойство-заполнитель, я планирую создать и заполнить значения в бине, который, в свою очередь, используется приложением.

Бывают случаи, когда файл свойств изменяется и в этом случаеЯ хочу, чтобы бин отражал измененные значения.Я понимаю, что ApplicationContext.refresh () - это способ обновления bean-компонента и его значений конфигурации.ApplicationContext.refresh () работал как шарм.

<context:property-override location="file:///d:/work/nano-coder/quickhacks/src/main/resources/myproperties.properties"/>

<bean id="myconfig" class="org.nanocoder.quickhacks.config.MyPropertyBean">
    <property name="cacheSize" value="${registry.ehcache.size}"/>
    <property name="httpHostName" value="${url.httpHostName}"/>
    <property name="httpsHostName" value="${url.httpsHostName}"/>
    <property name="imageServers">
        <list>
          <value>${url.imageserver1}</value>
          <value>${url.imageserver2}</value>
          <value>${url.imageserver3}</value>
        </list>
    </property>

</bean>

Однако при обновлении контекста я обнаружил, что одновременные вызовы ApplicationContext.getBean () или любой операции получения для bean-компонента потенциально не выполняются из-за IllegalStateException или BeanCreationException .

value = context.getBean("myconfig", MyPropertyBean.class).getHttpHostName();

Вопросы

  1. Возможно ли, что вызовы context.refresh () не влияют на другие одновременные вызовы
  2. если context.refresh () может нарушить одновременный доступ к контексту приложения, существуют ли какие-либо стратегии, позволяющие избежать этого.

Ваши указатели будут высоко оценены.

1 Ответ

1 голос
/ 03 октября 2011

Что вы можете сделать, это создать некоторую оболочку вокруг вашей службы конфигурации и вместо обновления существующего контекста создать новый.Когда новый будет готов, начните использовать его вместо старого.

Я не уверен, что это лучший выбор для управления конфигурацией, но код может выглядеть следующим образом (позже можно было бы хотя бы ввести интерфейс без зависимости от пружины): 

class MyConfig {
  private ApplicationContext context;

  public ApplicationContext getContext() {
    return context;
  }

  public void refresh() {
    context = new FileSystemXmlApplicationContext(..)
  }
}
...