Создайте класс Singleton [дубликат]

Question

Создайте класс Singleton [дубликат]

Вы также можете извлечь вне обратного блока:

render: function() {
    var rows = [];
    for (var i = 0; i < numrows; i++) {
        rows.push(<ObjectRow key={i}/>);
    } 

    return (<tbody>{rows}</tbody>);
}

7

java design-patterns jvm singleton

задан Rahul Agrawal 21 August 2012 в 06:06

2 ответа

Singleton обеспечивает только один экземпляр класса в данной JVM.

В чем проблема с несколькими DBManagers, по одному для каждой JVM, в вашем случае?

0

ответ дан Vikdor 3 September 2018 в 17:10

Другие вопросы по тегам:

java design-patterns jvm singleton

Похожие вопросы:

score 6 · Accepted Answer

Java дает вам один сингл в каждом экземпляре, вам нужна какая-то координация между экземплярами, поэтому в любой момент времени один из них активен, но если активный умирает, то другой экземпляр становится активным.

Некоторые серверы приложений имеют встроенные возможности для управления такими скоординированными рабочими экземплярами, я не знаю, имеет ли Tomcat такую функцию.

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

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

Идея заключается в том, что запись содержит временную метку «reservedUntil» и «processId». Каждый процесс считывает запись, если он содержит свой собственный идентификатор, а временная метка еще не истекла, он знает, что он может работать. Когда время почти истекло, активный процесс обновляет временную метку, используя оптимистичный стиль блокировки «Обновить, где timestamp == old timestamp» для управления условиями гонки. Каждый неактивный процесс ожидает, пока временная метка, которую он прочитал в последний раз, истекла, а затем попытается взять управление, обновив запись, снова используя оптимистическую блокировку Update где. Обычно эта попытка захвата будет терпеть неудачу, но если она преуспеет, у нас теперь будет новый активный экземпляр, и из-за оптимистической блокировки мы можем получить только один активный экземпляр.