If you are going to use Terracotta you really do need to design for it - even if it could in theory wrap a naive design, you'll probably thrash the network.
Some ideas for Terracotta friendly design I can think of, right off the bat:
1. If this node is the only one using this particular shared data structure right now, it gets to operate locally without network transactions until it's done.
2. If you consistently use a small part of a large data structure (eg: a hash), you'll only have that small part "paged in" on that one node. The whole data structure can be larger than RAM. Thus, node affinity can be important.
3. Be careful how much work is done inside a synchronized method of a shared data structure. It should be a medium amount. Too much, and you'll make other users wait, too little and you'll thrash the network.
Some ideas for Terracotta friendly design I can think of, right off the bat:
1. If this node is the only one using this particular shared data structure right now, it gets to operate locally without network transactions until it's done.
2. If you consistently use a small part of a large data structure (eg: a hash), you'll only have that small part "paged in" on that one node. The whole data structure can be larger than RAM. Thus, node affinity can be important.
3. Be careful how much work is done inside a synchronized method of a shared data structure. It should be a medium amount. Too much, and you'll make other users wait, too little and you'll thrash the network.