Как Терракота работает в этой ситуации?

Question

Итак, допустим, у меня есть N размер серверного массива настроен следующим образом:

альтернативный текст http://www.terracotta.org/web/download/attachments/43909161/ServerArrayMirrorGroup.png

У меня есть простой JavaBean / POJO:

package example;

public class Person {
  private OtherObject obj;

  public void setObj(OtherObject theObj) {
    synchronized (this) {
      obj = theObj;
    }
  }

  public OtherObject getObj() {
    synchronized (this) {
      return obj;
    }
  }
}

Теперь, если один из Клиентов вызывает Person.setObj(OtherObject) для объекта Person в корне TC (структура данных), является синхронизированный блок (лично.setObj(OtherObject)) на этом клиенте, удерживаемом:

1) Пока все N из серверов в N размер серверного массива был синхронизирован / обновлен с этим атрибутом Person.obj?

или

2) До тех пор, пока "активный" сервер не будет синхронизирован с этим обновленным атрибутом Person.obj?Затем другой (N-1) серверы в массиве синхронизированы, насколько это возможно?

или

3) Какой-то другой метод, который я просматриваю?

Answer 1

Ответ на самом деле не 1 и не 2.Объекты распределены по группам зеркал сервера.При первом задании этого поля создается транзакция, и после этого зеркальная группа, выбранная для этой первой транзакции, будет "владеть" объектом.

Что касается как 1, так и 2, не все группы активных серверов нуждаются в обновлении, поэтому нет необходимости ждать выполнения любого из этих условий.

Вы можете найти более подробную информацию в документации Terracotta о настройке массива серверов Terracotta:

• http://terracotta.org/web/display/docs/Terracotta+Server+Arrays

С точки зрения блокировки, кластерная блокировка этого объекта Person будет сохраняться (взаимное исключение по всему кластеру) во время выполнения модификации объекта.Область действия синхронизированного блока формирует транзакцию, упомянутую выше.В методе getObj() вы могли бы настроить это как блокировку чтения, которая позволила бы нескольким одновременным считывателям по всему кластеру.

Answer 2

Предположим, что у всех остальных есть ссылка на ваш объект и они могут прикоснуться к нему во время / до / после того, как вы это сделаете.Таким образом, решением было бы добавить блокировки, и

• получить блокировку
• измените объект
• отпустите блокировку

И это именно то, что синхронизированный делает...это создает очередь, и синхронизированный метод не может быть вызван более одного раза...но базовый объект может быть затронут, если на него где-то есть ссылка.

видишь:

• http://www.terracotta.org/web/display/orgsite/Hello+Clustered+World
• http://www.terracotta.org/web/display/orgsite/Tutorials

Answer 3

Я не знаком с их реализацией (Terracotta), но с точки зрения JMM, это следует возьмите замок размером с кластер.Однако этот пример очень прост;просто изменение ссылки, и это может привести к ее преобразованию во что-то, что больше похоже на изменчивую запись, и полностью избежать блокировки.

Но, если вы делаете нетривиальные вещи в своем синхронизированном блоке, то я бы предположил, что TC пессимистично принимает блокировку всего кластера в начале синхронизированного блока.Если бы они этого не сделали, они были бы в противоречии со спецификацией JMM.как я это понимаю.

Другими словами, ваш вариант №1.Итак, будьте осторожны с тем, что вы разделяете в кластере, и используйте неизменяемые объекты и структуры данных java.util.concurrent.*, когда можете - последнее пользуется особой любовью в TC.