[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Field level changes to objects  XML
Forum Index -> Terracotta Platform
Author Message
Sriram

neo

Joined: 06/29/2006 07:37:40
Messages: 8
Offline

OS : Redhat Linux
JVM : JDK 1.5_06

I have been successful in doing some tests using Terracotta DSO. I have the following questions

1. I am able to get the changed object set through the Change Listener feature. Is there a way to even find which field in that object changed. For example I change say couple of strings in a object on one server. In the other server I want to be able to find which fields changed. The reason being that finally we need to push these changes to a windows client. So pushing the minimal data will immensely help reducing the bandwidth.

2. Do all the servers in a cluster need to be in a single LAN or could they be geographically spread.
bchever

journeyman

Joined: 05/24/2006 15:10:55
Messages: 18
Offline

Sriram,

Thank you for writing.

A Terracotta WAN-based deployment is on the roadmap, but the current product is designed for a LAN environment.

I'll check with Engineering on whether there's a way to recognize the pushed deltas as you describe. What is the Windows client written in?


Bill Chever
Product Support Manager
Terracotta, Inc.
Sriram

neo

Joined: 06/29/2006 07:37:40
Messages: 8
Offline

Thank for the prompt reply.

The windows client is written in MFC/Visual C++.

bchever

journeyman

Joined: 05/24/2006 15:10:55
Messages: 18
Offline

Sriram,

While there is nothing in the Terracotta products that will inform you of field-level changes, you could write something yourself that would keep track of those changes and then send the data to your client. Think of solving the problem in the same way you would when writing for a single VM. Just add fields that are populated when someting changes as a collection, and then clear that collection when the deltas are pushed to your C++ client.

With respect to operation on a WAN, let me explain further. There is nothing in our products that will prevent you from running on a WAN, but you need to understand that we do no security with our products, and, of course, there is nothing we can do about physical latency, i.e., if your network bandwidth is very large, DSO will work with no issues.


Bill Chever
Product Support Manager
Terracotta, Inc.
Sriram

neo

Joined: 06/29/2006 07:37:40
Messages: 8
Offline

We have to support close to 100,000 concurrent connections and being a Gaming provider, the performance is very criticial.

I have 3 questions/observation :

1. The only issue i saw doing it myself is that by the time the change listener is called the master object is already modified, which means I have lost the original state. So I have to keep track of a copy object which represents the old state (maintained at the time the last push was done to the C++ client) and then every time I want to push the changes to the C++ client just compare every field in the master object with the copy object and then just push only those changes. I feel this will be too much CPU cycles.

2. Also would it be possible to engage your professional service team to provide us with any customization/hooks to ur code, which will allows us to identify the exact fields that were changed in any object.

3. Also I notiiced that if the change was to a Object (like a java.util.Date) vs a primitive type like int/string, it sends us the new changed object (java.util.Date) in the change listener handler. Any insights to this.
bchever

journeyman

Joined: 05/24/2006 15:10:55
Messages: 18
Offline

Hi Sriram,

1. "So I have to keep track of a copy object which represents the old state (maintained at the time the last push was done to the C++ client) and then every time I want to push the changes to the C++ client just compare every field in the master object with the copy object and then just push only those changes."

There are a variety of ways to approach this. Along with #2, I will request our Professional Services team contact you to gather more specifics as to your requirements.

"3. Also I noticed that if the change was to a Object (like a java.util.Date) vs a primitive type like int/string, it sends us the new changed object (java.util.Date) in the change listener handler. Any insights to this."

The Java util classes are special cases that cannot be named locked, if that is what you tried. Instead of placing the lock on the actual add method of the java.util class, put the lock on the methods that are doing the calling.

Regards,



Bill Chever
Product Support Manager
Terracotta, Inc.
Sriram

neo

Joined: 06/29/2006 07:37:40
Messages: 8
Offline

The way I say java.util.Date behaviou is that it was a field in a wrapper object. When I changed the date field, in the chane listener I say notification for the Date field getting changed and also the wrapper object getting changed. BTW the lock was on a method which had all these logic and not on the java.util.Date methods.

Is there a specific person I need to call in Professional Services ? Could I talk to u, since u are aware of my problem.
bchever

journeyman

Joined: 05/24/2006 15:10:55
Messages: 18
Offline

Hi, Sriram.

I'll send you a private message to get contact info.

Regards,

Bill Chever
Product Support Manager
Terracotta, Inc.
zeeiyer

consul

Joined: 05/24/2006 14:28:28
Messages: 493
Offline

Hello Sriram:

I dropped you an email and we'd be happy to discuss the use-case in greater depth on July5. There seems to be a few questions in here and here is a summarization response, based on an internal discussion.

a.
Certain classes are immutable so they wouldn't be present in the change callback. Examples include:
- all the primitive wrapper classes (Integer, etc)
- java.lang.String
- java.lang.Class
- java.lang.StackTraceElement
- any non-portable object.
Other mutable objects that can change will be passed over to the change listener.

b.
In your example, additionally, you could be continuously passing over the changes to the MFC/C++ client - and the client applies changes, if the extent of the changes are small and hence network bandwidth consumption is reasonable/minimal. If that assumption is incorrect, then there would be, it seems, merit in an intermediary layer to compare deltas between object changes over a certain interval and pushes the net-change at the end of some predefined time-intervals, for example.

Iyer.


Sreeni Iyer, Terracotta.
Not a member yet - Click here to join the Terracotta Community
 
Forum Index -> Terracotta Platform
Go to:   
Powered by JForum 2.1.7 © JForum Team