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

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 (структура данных), это синхронизированный блок (в Person.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

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

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

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