Terracotta Discussion Forums

I'm a little confused with root definition.

Here is an example:

public abstract class ClassA {
public boolean flag;
}

public class ClassB extends ClassA {}

public class ClassC extends ClassA {}

I want to define two different roots pointing to attribute "flag" - one for all instances of ClassB and another one for all instances of ClassC.

Is it possible?

Regards.

Why?

You should think of roots like public static final variables. They take essentially a cluster wide static value.

So the question would be - what are trying to do that you want different classes that inherit from the same class to behave differently?

tgautier wrote:

Why?

You should think of roots like public static final variables. They take essentially a cluster wide static value.

So the question would be - what are trying to do that you want different classes that inherit from the same class to behave differently?

well i already have developed application and i just want to inject cluster functionality into it using terracotta.

The idea is that i have more then one server where application is going to run and ClassB and ClassC are singletons actually (they have similar system functionality but business logic is different) and I really don't need them to share the same attribute value. I mean the instances of ClassB running on different servers should share its value of attribute which that class is inherited from ClassA. The same is true for ClassC.

As far as I understand I can achieve that only if I just copy that attribute from ClassA to ClassB and ClassC (with all common system logic)

Is it right?

So let's see, you have Application A and Application B. And then you have Application Server 1, Application Server 2, and finally TC Server 1.

Will A and B run on App Server 1 and App Server 2, each connected to TC Server 1?

tgautier wrote:

So let's see, you have Application A and Application B. And then you have Application Server 1, Application Server 2, and finally TC Server 1.

Will A and B run on App Server 1 and App Server 2, each connected to TC Server 1?

well i have one Application but two instances of that application running on two different physical boxes (it is not j2ee app but simple standalone application, not even gui) - i just want both those application to share some internal component's state.

well i have one Application but two instances of that application running on two different physical boxes (it is not j2ee app but simple standalone application, not even gui) - i just want both those application to share some internal component's state.

If I understand what you're trying to do, then you could just declare flag as root, making its state shared across instances of your application.

If you want to explore TC to understand how things work, I suggest (in addition to this Forum) using the POJO Archetype we have in the Forge. It'll help you setup a simple project very quickly, complete with a basic TC configuration: http://forge.terracotta.org/releases/projects/pojo-archetype/docs/quickstart.html

You'll need to have (at least) Maven 2.0.9 installed.

zalexs wrote:

I want to define two different roots pointing to attribute "flag" - one for all instances of ClassB and another one for all instances of ClassC.

I'm not sure the responses thus far have answered your question. I'm new at this, but I was just chatting with one of the more experienced engineers and I think the answer is "no."

Here's how he put it: "the simple answer is that the server won't keep same-named roots from different applications separate. There is a single namespace for all roots in the server. A root's name is the fully qualified field name. It doesn't matter if a field is defined in more than one classloader, there is no scoping other than the name."

So in your case, you have two different applications, but they both happen to have a root named org.xyz.A.flag. The server has no way of telling these apart. It does not understand that they came from different applications.

I suppose one answer might be to run two separate TC servers, on different physical hosts or different ports, to keep the applications separate.

One small correction.
The fully qualified name of a field is the DEFAULT name for a root.
You can name a root what ever you want. The root def is actually a connection between a root (with an arbitrary name) and the field you are connecting it to.
Cheers,
Steve

steve wrote:

One small correction.
The fully qualified name of a field is the DEFAULT name for a root.
You can name a root what ever you want.

So perhaps zalexs could simply name the roots differently in the two applications? That would be a very easy fix. (Leads me to think, for users with multiple applications, perhaps we should recommend as standard "best practice" that they rename all roots with a name that is scoped to the application.)

wharley wrote:

steve wrote:

One small correction.
The fully qualified name of a field is the DEFAULT name for a root.
You can name a root what ever you want.

So perhaps zalexs could simply name the roots differently in the two applications? That would be a very easy fix. (Leads me to think, for users with multiple applications, perhaps we should recommend as standard "best practice" that they rename all roots with a name that is scoped to the application.)

Well that what I did - didn't work. The good approach would be to have the ability to define the roota as:
public boolean ClassB.super().flag
public boolean ClassC.super().flag

but it doesn't work.

The simple solution is just move that flag from ClassA to ClassB and ClassC - but I just don't like it.

zalexs wrote:

The good approach would be to have the ability to define the roota as:
public boolean ClassB.super().flag
public boolean ClassC.super().flag

With all respect, I don't think that's the right approach. It would work in this particular case, but it does not address the equally likely scenario where someone has two applications that both contain a same-named root that is not subclassed. For instance, two applications that include the same third-party jar with a root in it.

The right approach is for roots to be scope-able by application. This could in principle be done manually by naming (but it sounds like that is not working for you, so we need to investigate) or automatically by classloader scoping (but that would not necessarily always do the right thing).

As an immediate workaround, is it possible in your case to use two separate Terracotta servers?

wharley wrote:

zalexs wrote:

The good approach would be to have the ability to define the roota as:
public boolean ClassB.super().flag
public boolean ClassC.super().flag

With all respect, I don't think that's the right approach. It would work in this particular case, but it does not address the equally likely scenario where someone has two applications that both contain a same-named root that is not subclassed. For instance, two applications that include the same third-party jar with a root in it.

The right approach is for roots to be scope-able by application. This could in principle be done manually by naming (but it sounds like that is not working for you, so we need to investigate) or automatically by classloader scoping (but that would not necessarily always do the right thing).

As an immediate workaround, is it possible in your case to use two separate Terracotta servers?

Well - i don't understand how two different terracotta servers can solve the problem. I'm feeling that may be i incorrectly explain the difficulties I have.

will try again:

use case (1)
have two singleton classes ClassB and ClassC in one application (no common parent) each of the classes has some attributes, let say it's boolean flag (which exists in ClassB and ClassC) and some other (for example ClassB has int counterB and ClassC int counterC).
everything is working good: I just define four roots in config files and the application running on two different JVMs sharing the states of ClassB (flag and counterB) and ClassC (flag and counterC). They also have another attributes which are also defined as different roots (named or not named - doesn't matter)

use case (2)
I introduce ClassA as a parent of ClassB and ClassC and move all common attributes (in my scenario its a boolean flag) into ClassA - so the question is how can I define roots (in my scenario for boolean flag) now - if i don't want to share the state of flag between ClassB and ClassC in the same application.

The problem for me right now that I need to slightly rework already developed and tested code to make it work under terracotta as I expected.

That's the only issue and I'm just trying to understand may be I just don't know how to define roots properly.

Thank you everyone in advance.

Just to get us all on the same page, your scenario is something like (at least on use case 2):

Code:

 class A {
    public int flag;
 }
 
 class B extends A {
   public void status() {
     System.out.println(flag);  // prints 909 
     System.out.println(C.instance().flag);  // prints 606 
   }
 
   public static B instance() {
     new B();
   }
 
   B() {
     flag = 909;
   }
 }
 
 class C extends A {
   public void status() {
     System.out.println(flag);  // prints 606 
     System.out.println(B.instance().flag);  // prints 909 
   }
 
   public static C instance() {
     new C();
   }
 
   C() {
     flag = 606;
   }
 }

Basically you want to be able to separately articulate the values for the inherited attributes but let instances of B and C be able to see/share these values with each other.

Is that correct?

jgalang wrote:

Is that correct?

Yeap.....(instances of B on different JVMs as well as instances of C but not between B & C)

zalexs wrote:

i don't understand how two different terracotta servers can solve the problem. I'm feeling that may be i incorrectly explain the difficulties I have.

Apologies - you're right, I'm not sure why I thought you had two applications. With just one app, using multiple servers would be both impossible and unfruitful.