Recently I got familiar with Terracotta NAM. NAM is a Network Attached Memory, approach that is quite different in comparison with grid technology. I often hear that Terracotta, GigaSpaces and GridGain are grid products but let me deny it and point out to the conceptual differences between for example Terracotta and GridGain.
Cluster vs. Grid.
As I already said Terracotta is a network attached memory or another words meta/clustered JVM. This means that you as administrator of this cluster certainly knows that your application is being executed on the clustered JVM but from developer standpoint it's just a single JVM with some "very special" configuration. This is a cluster where you usually don't know about all nodes behind your local one.
Unlike the NAM, grid technology provides comprehensive view on all nodes in grid. You can get information about every node and even more of that you can send your code to be executed on certain node.
Task vs. Application.
Terracotta works with your application as is. You don't need to rewrite it, change your code. Of course there are some recommendations to make application more flexible and scalable but your application will work fine with Terracotta without even a single change.
Unlike the NAM, grid technology gives you task/job-oriented approach where you have to define tasks/jobs as portions of work to be executed remotely. This approach is different to say orthodox one and one need to change his/her mind back from object-oriented to task/procedure-oriented one.
Underlying implementation approach.
Terracotta's clustering behavior is injected into application code at runtime by the use of bytecode instrumentation. By defining your own configuration you let Terracotta know what code/objects should be "networked" and Terracotta will substitute your code with new. So when you create new object handled by Terracotta you should assume that your object will be sent out to another box in cluster. Terracotta server will handle all fails and guarantee that object is alive even if your local box failed.
Again unlike the NAM, GridGain implemementation (and most of grids) is a ordinary Java one. It does not instrument you code or change it somehow usually. Of course GridGain for example gives simple yet powerful Asspect-oriented way to gridify your code but to get full control it's better to write own tasks and jobs.
Integration.
Terracotta integrates with a bunch or products by implementing say a kind of plugins. As for grids they usually require no special integration - you can install product on every node and run your code.
So to sum it up, grid and NAMs are quite different and it's a mistake to mix them together.
Cluster vs. Grid.
As I already said Terracotta is a network attached memory or another words meta/clustered JVM. This means that you as administrator of this cluster certainly knows that your application is being executed on the clustered JVM but from developer standpoint it's just a single JVM with some "very special" configuration. This is a cluster where you usually don't know about all nodes behind your local one.
Unlike the NAM, grid technology provides comprehensive view on all nodes in grid. You can get information about every node and even more of that you can send your code to be executed on certain node.
Task vs. Application.
Terracotta works with your application as is. You don't need to rewrite it, change your code. Of course there are some recommendations to make application more flexible and scalable but your application will work fine with Terracotta without even a single change.
Unlike the NAM, grid technology gives you task/job-oriented approach where you have to define tasks/jobs as portions of work to be executed remotely. This approach is different to say orthodox one and one need to change his/her mind back from object-oriented to task/procedure-oriented one.
Underlying implementation approach.
Terracotta's clustering behavior is injected into application code at runtime by the use of bytecode instrumentation. By defining your own configuration you let Terracotta know what code/objects should be "networked" and Terracotta will substitute your code with new. So when you create new object handled by Terracotta you should assume that your object will be sent out to another box in cluster. Terracotta server will handle all fails and guarantee that object is alive even if your local box failed.
Again unlike the NAM, GridGain implemementation (and most of grids) is a ordinary Java one. It does not instrument you code or change it somehow usually. Of course GridGain for example gives simple yet powerful Asspect-oriented way to gridify your code but to get full control it's better to write own tasks and jobs.
Integration.
Terracotta integrates with a bunch or products by implementing say a kind of plugins. As for grids they usually require no special integration - you can install product on every node and run your code.
So to sum it up, grid and NAMs are quite different and it's a mistake to mix them together.
2 comments:
"o when you create new object handled by Terracotta you should assume that your object will be sent out to another box in cluster."
That's not true - or at least not precise enough. The object will be local until you add it to the object graph of one of the configured roots.
For an example, assume _accounts is some Collection configured as root and the Accounts class is instrumented by Terracotta:
Account a = new Account(); // local
synchronized (_accounts) {
_accounts.put(a); // clustered
}
The synchronized block is important, as synchronized blocks yield Terracotta transactions (which is done using byte code instrumentation).
Exactly, saying "handled" I meant either root or one of the objects in the root's graph as described on Terracotta's pages.
Yes synchronization is important, otherwise you will get an exception.
Post a Comment