Terracotta 在这种情况下如何工作？
假设我有一个 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。 TC 根（数据结构）中的 Person 对象上的 setObj(OtherObject) 是该客户端上的同步块（在 Person.setObj(OtherObject) 中）：
1) 直到所有 N N 大小的服务器阵列中的 服务器已与该 Person.obj 属性同步/更新？
或
2) 直到“活动”服务器与更新的 Person.obj 属性同步？ 那么阵列中的其他（N-1）服务器是否尽可能同步？
或
3）我忽略的其他方法？
So lets say I have an N sized server array set up like so:
alt text http://www.terracotta.org/web/download/attachments/43909161/ServerArrayMirrorGroup.png
I have a simple 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;
}
}
}
Now if one of the Clients calls Person.setObj(OtherObject) on a Person Object in the TC root (data structure), is the synchronized block (in Person.setObj(OtherObject)) on that client held:
1) Until all N of the Servers in the N sized server array have been synchronized/updated with that Person.obj attribute?
or
2) Until the "active" server has been synchronized with that updated Person.obj attribute? Then the other (N-1) servers in the array are synchronized as possible?
or
3) Some other method that I am over looking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
答案实际上并不是 1 或 2。对象在服务器镜像组中条带化。 第一次设置此字段时，将创建一个事务，并且为第一个事务选择的镜像组将“拥有”该对象。
对于 1 和 2，并非所有活动服务器组都需要更新，因此无需等待其中任何一个条件。
您可以在 Terracotta 文档中找到有关配置 Terracotta 服务器阵列的更多信息：
从锁定的角度来看，在执行对象修改时，会持有此 Person 对象上的集群锁（跨集群互斥） 。 同步块的范围形成了上面提到的事务。 在 getObj() 方法中，您可以将其配置为读锁，这将允许集群中的多个并发读取器。
The answer is not really 1 or 2. Objects are striped across the server mirror groups. The first time this field is set, a transaction is created and that mirror group chosen for that first transaction will "own" the object after that.
With respect to both 1 and 2, not all active server groups need to be updated so there is no need to to wait for either of those conditions.
You can find more info at the Terracotta documentation about configuring the Terracotta server array:
From a locking point of view, the clustered lock on this Person object would be held (mutual exclusion across the cluster) while performing the object modification. The scope of the synchronized block forms the transaction mentioned above. In the getObj() method, you could configure this as a read lock which would allow multiple concurrent readers across the cluster.
假设其他人都有对您的对象的引用，并且可以在您这样做时/之前/之后触摸它。 因此，解决方案是添加锁，并
，这正是 Synchronized 所做的......它创建一个队列，而 Synchronized 方法可以'不会被多次调用...但是如果底层对象在某处被引用，则可能会被触及。
请参阅：
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
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 悲观地在同步块的开头获取了集群范围的锁。 如果他们不这样做，他们就会与 JMM 规范不一致。 据我了解。
换句话说，你的选择#1。 因此，请小心在集群中共享的内容，并尽可能使用不可变对象和 java.util.concurrent.* 数据结构 - 后者在 TC 中得到了特殊的内在喜爱。
I'm not familiar with their (Terracotta) implementation, but from a JMM standpoint, it should take a cluster-wide lock. However, this example is very simple; just a change of a reference, and that may cause it to be converted into something that is more like a volatile write, and completely avoid locking.
But, if you do non-trivial stuff in your synchronized block, then I would assume that TC pessimistically takes a cluser-wide lock at the start of the synchronized block. If they didn't, they would be at odds with the JMM spec. as I understand it.
In other words, your option #1. So, be careful what you share in the cluster, and use immutable objects and java.util.concurrent.* data structures when you can - the latter is getting special intrinsic love in TC.