This link has been bookmarked by 35 people . It was first bookmarked on 30 Mar 2007, by Christian Winkler.
-
27 Oct 15
-
07 Jan 15
-
JVM-level clustering simplifies enterprise Java by enabling applications to be deployed on multiple JVMs, yet interact with each other as if they were running on the same JVM
-
This approach is much more efficient than replication by serialization because it only moves the data that has changed across the cluster instead of entire serialized object graphs. But, aside from efficiency, there is a critical architectural benefit to using object fields as the units of change: preservation of object identity.
-
-
13 Mar 14
-
29 Aug 13
-
In a single JVM, threads interact with each other through changes made to objects on the heap and through the language-level concurrency primitives: the 'synchronized' keyword and the Object methods wait, notify, and notifyAll. Open Terracotta allows threads in a cluster of JVMs to interact with each other across JVM boundaries using the same built-in JVM facilities extended to have a cluster-wide meaning. These clustering capabilities are injected into the bytecode of the application classes at runtime, so there is no need to code to a special clustering API.
-
-
02 Jan 13
-
12 Oct 12
-
06 Apr 11
-
09 Aug 10
-
05 Aug 10
-
12 Feb 10
-
02 Jul 09
-
22 Apr 09
-
bytecode injection
-
To maintain object changes, the PUTFIELD and GETFIELD bytecode instructions are overloaded. PUTFIELD instructions are trapped to record changes to a clustered object's fields. GETFIELD bytecode instructions are trapped to retrieve object data from the server as needed, if it hasn't already retrieved the object referenced by the field in question from the server and instantiated it on the heap.
To manage thread coordination, the MONITORENTER and MONITOREXIT bytecode instructions are overloaded as well as the INVOKEVIRTUAL instructions for the various Object.wait() and Object.notify() methods. MONITORENTER signifies the request of a thread for an object's monitor. A thread will block at this instruction until it is granted the lock on that object. Once the lock is granted, that thread holds an exclusive lock on that object until the MONITOREXIT instruction is executed for that object. If the object in question happens to be a clustered lock, Terracotta ensures that, in addition to requesting the local lock on that object, the thread also blocks until it receives the exclusive cluster-wide lock on that object. When the thread releases the local lock, it releases the corresponding cluster-wide lock.
-
Their field data is shipped down to and stored by the Terracotta server
-
the Terracotta transparency libraries retrieve the root from the server, instantiate it on the local heap, and assign a reference to it to the root variable in question.
-
-
10 Mar 08
-
-
05 Sep 07
DJHell .Java applications are easiest to write and test when they run in a single JVM. However, the requirements to make applications scalable and highly available have forced Java applications to run on more than one JVM. In this article, we introduce OpenTerrac
cluster clustering Einführung infoQ Java JEE OpenTerracotta Terracotta verteiltes Rechnen development articles
-
11 Jun 07
-
01 Apr 07
-
19 Mar 07
-
21 Feb 07
-
14 Feb 07
-
13 Feb 07
-
Keith LoOpenTerracotta is an open source enterprise-class JVM clustering solution that can take multi-threaded single-JVM apps and have them run across multiple JVMs with no code changes. Orion Letizi goes super-indepth on Terracotta and how it works, explaining
-
12 Feb 07
-
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.