Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

I came across reference to the fact that the terracotta servers pushes object changes only to those VM's where the object is resident.

I would like to know how I can indicate that a client is interested in changes only to a partiicular object. I noticed that the dso root section in the configuration XML applies to all the clients.

Hello Sriram.

Terracotta pushes changes to the places where the data is needed automatically - i.e. there are no APIs that indicate where the data is needed.

The way we do this is by clustering the JVM. By clustering the JVM, your code does not have to be changed in any way to indicate where the data is resident or what changes need to be pushed.

The semantics for how this works follows the Java Memory Model. The basic idea is that what works in a single VM with multiple threads will work across multiple VMs with multiple threads.

To answer your question specifically, a Terracottta configuration file is needed to specify the "root" of the object graph that is shared across multiple VMs. The root is specific to each application, an example is the HTTP Session Manager in a clustered App Server. You will have to examine your application and decide what root (or roots) need to be shared. Once that is done, all references the root makes to other objects are automatically shared. This graph of objects becomes the basis for data that is shared across the cluster.

The "unit of change" - i.e. what changes get pushed when - is defined by a lock - using the standard java synchronized keyword. Anytime your code acquires a lock, Terracotta will automatically step in and if changes to the object(s) referenced in the lock (that are a part of the DSO object graph shared from the root) were made elsewhere - either in the same VM on a different thread or a different VM in a different thread - the changes are applied and your code is guaranteed to see the latest version.

I hope that helps.

Taylor

Thanks for the reply. My exact use case is as follows

1. I have 4 clients (Client 1 --- 4) connecting to a terracotta server

2. I want to share two different object roots (DSO_A , DSO_B)

3. Client 1 and Client 2 wants to see changes to the root object tree DSO_A

4. Client 3 and Client 4 wants to see changes to the root object tree DSO_B

QUESTIONS
**********

5. How does Client 1 and Client 2 say it needs only changes to DSO_A
and NOT changes to DSO_B

6. How does Client 3 and Client 4 say it needs only changes to DSO_B
and NOT changes to DSO_B

Sorry my QUESTIONS are as follows

6. How does Client 3 and Client 4 say that it needs changes to DSO_B and NOT changes to DSO_A

Hi Sriram,

Again, the mechanism is to just use natural Java semantics - what works with natural Java in a single VM works with Terracotta and multiple VMs.

In natural Java with a single VM, there is no mechanism to tell the VM to ensure that the most current state of an object is available for a thread when the thread needs to read it because that kind of an API is not necessary and would be overly cumbersome - instead that kind of guarantee is simply a basic constraint defined by the Java Memory Model and satisfied by the VM. When using Terracotta the same constraint is applicable and the clustering of VMs happens behind the scenes so that the same guarantee is satisfied by the set of VMs using Terracotta.

As a thought excercise, imagine you have several threads running on a multiprocessor system - in this case each is working on it's own copy of an object, synchronization of state only happens at the lock boundary. This procedure - synchronizing state at the lock boundary by transmitting data between the processors in a single VM - is exactly analgous to multiple VMs synchronizing state at the lock boundary across the network using Terracotta.

Thus, in your case, if client 1 and client 2 are working on the data set that is represented by the object root DSO_A, then they will be referencing objects within that data set and they will see the current changes (synchronized at lock boundaries). Since they are not referencing objects from the dataset referenced by DSO_B, then they will not be doing reads on the objects within that dataset, and therefore will not see the changes that happen from clients 3 and 4.

The same argument can be said about clients 3 and 4 (just switch datasets).

Taylor

Taylor. Thanks for the reply. Just wanted to confirm that clients are not pushed data by the terracotta server if they do not access it. So no network hogging for unneccessary data.

Hi Siriam

After reading this posting, I have a a almost similiar issue to ask you.

If the legacy code has been written such that Client 1 to 4 would read both DS0_A and DS0_B,is there any way to segregate such that Client 1 and 2 will only read DS0_A and client 3 and 4 only for DS0_B. Your reply seem to imply that the updates will not be applied only if the codes do not do so.

If this is the case it could result in scalability issue in the long run as if I would to scale the system from 1VMs to N no of VMs, I would need N x X amount of memory.

Regards

ent

Kent,

I guess I don't follow what you intend to do. If you had some examples I might be able better understand what it is you are looking for.

Thanks,

Taylor