Как Терракота работает в этой ситуации?
Как сказано в H. Блог Mijail , в repo sync --force-sync перезаписывает ваш существующий репозиторий! :
Похоже, что репозиторий отслеживает репозитории, которые он инициировал.
Поэтому, если вы создали хранилище независимо от репозитория, а затем добавили запись для этого существующего репозитория в манифест репо, синхронизация репозитория захлебнется и представит вам сообщение:error.GitError: --force-sync not enabled; cannot overwrite a local work tree. If you're comfortable with the possibility of losing the work tree's git metadata, use `repo sync --force-sync mydirectory` to proceed.Получается, что «метаданные git» "означает весь каталог
.gitвнутри mydirectory.
Таким образом, любая ветка, любой тайник, что-либо в вашем существующем локальном хранилище будет уничтожено. Также не используйте reflog!Как только вы запустите
repo --force-sync, репозиторий будет принят репо на дальнейшие вызовы синхронизации репо.Альтернативой использованию
blockquote>--force-syncмогло бы быть использование--force-break(или просто-f), которое просто происходит, когда какой-либо каталог не синхронизируется.
Но я не пытался, и я не знаю, как это могло бы иметь смысл, если бы мы предположили, что репо не попадает в каталог, который он не создал.В любом случае ... сначала сделайте резервную копию вашего локального репо!
3 ответа
Ответ на самом деле не 1 или 2. Объекты распределяются по группам зеркал сервера. При первом задании этого поля создается транзакция, и эта группа зеркал, выбранная для этой первой транзакции, будет «владеть» объектом после этого.
Что касается 1 и 2, то не все активные группы серверов необходимо обновлять, поэтому нет необходимости ждать ни одного из этих условий.
Дополнительную информацию о настройке терракоты можно найти в документации по терракоте. массив серверов:
С точки зрения блокировки кластерная блокировка для этого объекта Person будет сохраняться (взаимное исключение через кластера) при выполнении модификации объекта. Объем синхронизированного блока формирует транзакцию, упомянутую выше.
Assume that everyone else has a reference to your object and can touch it while/before/after you do. Thus the solution would be to add locks, and
- obtain lock
- modify the object
- release lock
And that's exactly what synchronized does... it creates a queue and the synchronized method can't be called more than once... but the underlying object might be touched if it's referenced somewhere.
see:
Я не знаком с их реализацией (Terracotta), но с точки зрения JMM он должен захватить блокировку всего кластера. Однако этот пример очень прост; просто изменение ссылки, и это может привести к тому, что она будет преобразована во что-то, что больше похоже на энергозависимую запись, и полностью исключит блокировку.
Но, если вы делаете нетривиальные вещи в вашем синхронизированном блоке, то я бы предположим, что TC пессимистически берет блокировку на уровне cluser в начале синхронизированного блока. Если бы они этого не сделали, они были бы в противоречии со спецификацией JMM. насколько я понимаю.
Другими словами, ваш вариант №1. Поэтому будьте осторожны с тем, что вы разделяете в кластере, и, когда можете, используйте неизменяемые объекты и структуры данных java.util.concurrent. * - последний приобретает особую внутреннюю любовь в TC.