Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

won't the distributed object B update itself 5 times

Am assuming that you are talking about a 5 JVM cluster where each of the VMs have a reference to object A. Now, A fires off a property-change event and in reaction to that, distributed object B gets changed. Is that correct ?

So the data-change (the mutated object B) would be cluster-wide. In that case, it seem we would only need DMI for the Swing method that repaints the screen. If on the other hand, object B is transient (and not replicated across the cluster) - then the method invocation in response to A's property-change event would need to be distributed.

if I somehow managed to get the connection to persist and distribute the "fire" method as per the tutorial

In the case where the "fire" method is distributed - and the resultant mutation is also distributed (object B), then there will be multiple mutations to object B across the cluster - which would not be OK, unless each mutation is idempotent.

It seems that in your example, B and C are listeners and given that "the list of listeners that the range model notifies upon change contains references to Swing objects that are display-specific", the list of eventListeners would be transient. So then just the "fire" and "local UI repaint" methods would need to be distributed (but not object B). OR if mutations to object B are distributed cluster-wide, then only would only need the "local UI repaint" method to be distributed.

It's quite possible that I have entirely misinterpreted the stated facts and/or intent of your question - if so please clarify. Will also look into the DSO Slider tutorial and post clarifications, if the confusion seems to be stemming from it.
Thanks

With regards to event propagation, it seems it can be accomplished with DMI in case of data-structures that are not "logically managed". (As mentioned earlier, there are some collections that in Terracotta are "logically managed" e.g. those that depend on a VM-specific-value such as hashcode, in which case data is replicated by essentially replaying actions)

Of course we'll have to try out the above scenario and the use-case you mention (perhaps after the break).

The other complication it seems, would be around defining correctness - i.e. what are the expectations around event delivery and sequencing gurarantees? Do Glazed Lists provide any? In case of DSO, given that state changes can persevere across VM restarts - there is the edge case where in case of a JVM loss, mutations to a DSO glazedList might persist before any resultant listeners actually execute on the node - so is there an expectation then that everything dictated by the Glazed Lists' listener dependency management in response to the mutation has to somehow be replayed, from a correctness perspective.

I suppose the application could be tasked with ensuring that GlazedLists's Listener Dependency Management and DMI don't collide - but we probably need to try out a few of these use-cases to ferret out any other hidden issues. Could you share the code around this use-case (private message, siyer@terracottatech.com), if possible, so we can try it out...

Regards
Iyer.

The "transactionality" entry in the Terracotta Product FAQ at http://www.terracotta.org/confluence/display/orgsite/FAQ#FAQ-ProductFAQ talks about this.

To illustrate this in your example :
Code:

 synchronized (customer) { //begin Terracotta transaction
    customer.setAge(30);
 } // end Terracotta transaction

As stated in the FAQ, mapping Terracotta transaction boundaries to those defined by an external transaction manager is not supported now, but is on the roadmap. Please drop me a PM or email (siyer@terracottatech.com) if you'd like to discuss your use-case in some greater detail.

Regards

Thanks for the post. I don't know if anyone else has tried this with Terracotta, but one of us at Terracotta can try it out and post back results...

The capabilities though with a glazedList with Terracotta DSO underneath it seem quite powerful- in that not only can the data be shared across the cluster, but so can the events (around addition/removal/modification of elements).

In the Terracotta world, collections are logically managed - i.e. mutations/adds/removes to a clustered collection are essentially replayed on the other nodes in the cluster. If the methods instead are methods not part of the natural Java spec, then again you could distribute those methods across the cluster with the DMI feature (Distributed Method Invocation) which essentially lets you simultaneously call a given method across all nodes that participate in the cluster.

Test message - please ignore.

Interesting use-case (as long as the clients are ok with dirty reads...)
Not having to deal with the object-relational impedance mismatch is a huge benefit as you rightly point out...Thanks for the comments...

Between Terracotta servers via the underlying persist mechanism's built in replication

Good points - Yes as I mentioned earlier, nothing is set in stone yet. The 2 approaches you point out are exactly the 2 approaches that we have discussed thus far - i.e.
* Rely on Berkeley DB replication options (easier to implement, but with less control) or
* Write object-DNA deltas asynchronously to a persistent queue and then having the remote TC Server apply the deltas with some default intelligence (and allow for pluggable intelligence such as interface implementations around security and/or conflict).

could rip out our current solution and replace it with Terracotta, which would provide a huge benefit to our development process. We might even consider throwing out the DB entirely and use DSOs, coupled with Terracotta's persist, exclusively, which would greatly reduce development time for new modules in our app.

Absolutely - for transient data you could use the Terracotta Server as the System or Record and with its transparency approach at delivering clustering as a service of the runtime, you will realize faster time-to-market. Security and asynch-replication across the WAN are on the roadmap, but the suggestion in the previous response of moving security concerns further up the software stack was just a temporary workaround, so you could realize the benefits of the Terracotta approach rightaway with the current (2.2) version

Regards.

Currently there is no encryption between the L1 and the L2 and of course, in the currently non-existent feature of inter-L2 replication across the WAN. However, the object state data persisted by the Terracotta server follows its own data-format rules and would require a bit of reverse engineering and effort to breach. (i.e. object field name/values are not simply readable as ascii text).

However, it is presumably possible to solve these issues at other tiers of the stack as against solving them with application's clustering infrastructure (i.e. Terracotta) e.g. the Java Application itself could presumaby encrypt and decrypt sensitive information and/or implement role-based access (so that the information is safe at source as against implementing it deeper down the software stack). Also the underlying network protocol for WAN transfer of Berkeley DB Files could be secure.

Does this sound workable ? In that it seems if we do encrypt data at the Java application tier, you could move forward with the product as it is today, instead of waiting until security related features get added.

since you use Berkeley DB, does it support an encrypted store?

I don't think the current version does, but I will research it and get back to you if I am incorrect.

Thanks though - several good points in your post - I will be sure to pass them on to our security related roadmap discusssions...Let us know if we can assist further - either on the forum or with a call or whatever works for you...
Regards
Iyer.

Effectively yes. The config-settings are not that direct though.

You specify when the eviction from the L1 cache to the L2 happens as a % of heap (and also what percent needs to be evicted). e.g. the default settings are when 70% of heap utilization is reached , evict 10% of the clustered object-graph to the Terracotta server from the application server. You may set java system properties and override the defaults, if desired...(e.g. l1.cachemanager.threshold=70, l1.cachemanager.percentageToEvict=10)

Regards
Iyer.

Java 1.5 support

Yes Terracotta supports Java 1.5. What the post might be referring to is that while we support a large swath of classes that typical applications use, we do not, as of now, have support for every single class in JDK1.5 - (e.g. as of now we do not support certain classes in java.util.concurrent - you could jar -tvf the dso boot-jar, although note that if a class isn't in the boot-jar it dosen't automatically mean that it is not supported) - but we'll soon be publishing a list on the .org site as well, with each release.

simply clusters the sessions in the JVM

Yes Terracotta is a clustering solution and does not concern itself with load balancing. It is location transparent in that it will work without sticky load balancing, but we'd recommend you stick with your current mechanism of sticky load balancing ;-), since maintaining "locality of reference" will result in improved performance and scale characteristics.

Apache+Jboss(tomcat 5.5)+ terracotta(sessions,spring,dso) works?

Tomcat 5.5 is a supported container. JBoss isn't currently supported although we have seen it work in lab-testing. And as we stated earlier, you can of course pre-front the App-server with Apache and a connector to handle static content and/or implement any needed load-balancing.

can one instance of the terracotta server manage all 500

We have had success with several hunded application servers connected to a single Terracotta server. However, the scale characteristics of such a configuration are heavily dependent on the extent of clustered I/O executed by the application. Almost all of the deployments thus far have worked with a single Terracotta server, given a lot of in-built batching, pipelining optimizations (there is a second Terracotta server that can deployed as a hot standby - although that is primarily for failure considerations). Also supporting multiple active Terracotta servers is on the roadmap (so perhaps sometime in the near future, we should have it) for those apps that execute such high levels of clustered I/O...

Yes - practically unlimited virtual heap. You are only bound theoretically by the size of the disk you can provision on your Terracotta server.

Terracotta Sessions is built on underlying core DSO (Distributed Shared Objects) technology and hence has the Virtual Memory feature baked into it - i.e. if your object graph (the collection containing all sessions) exceeds the size of your heap, portions of the object graph would reside on the Terracotta server and portions on disk and the appropriate portion (e.g. element of the collection) gets faulted in to a given application server's heap, on demand. As of today, we've tested this feature with object graphs in the range of 30G.

Hope that answers the question. Let us know if additional clarification is needed.
Regards,
Iyer.

Its not yet on SVN since it was more of a Strawman implementation. And current prioritizations, given internal resourcing issues, put asycnh replication across WAN support on more of a mid-term roadmap, as against an immediate roadmap.

The closest to a "sandbox" i can think of is the Forge concept on the terracotta.org site. Please check it out or the Community section on the .org site.
Regards
Iyer

Terracotta DSO currently does not have the transactionality features and support for certain classes that are needed to succesfully cluster Hibernate. While there is no formal prioritization, engineers are looking at it when they get some cycles.

With regards to the specific exception that you see, apologies the error message is a bit misleading, but Terracotta needs to add support for org.apache.commons.collections.ReferenceMap and java.util.AbstractMap.

We have a JIRA at https://jira.terracotta.org/jira/browse/CDV-31 around supporting Hibernate. Please vote for it so we can assess community interest.

Thanks

Terracotta passes the ACID (Atomic, Consistent, Isolated, Durable) test. Configuration can be exposed to ensure that changes from the client app-server to the Terracotta-server (L2) are persisted synchronously (currently by default, they are persisted asynchronously - failure to persist to the L2 results in a retry). To answer your specific questions:
1.
Currently there is no integration with JTA and/or other transaction managers. This feature of mapping Terracotta transaction boundaries (i.e. acquisition/release of a lock) to transaction boundaries defined by an external transaction manager is being discussed and will probably be added to the mid-term roadmap.
2.
Lock control with Terracotta can be fine-grained (i.e. map to the begin/end of a synchronized block-of-code or a "named lock" which maps to a method). Additionally objects that have low level synchronization semantics (java.util.concurrent, atomic classes of JDK15) are supported. Additionally one can define read (multiple readers, no writer), write (1 writer alone) or concurrent (no locking) types of locks. One does need to configure such that the locking is not too coarse-grained - and if the application supports read/concurrent access then utilize those types of locks by all means.
3.
Terracotta is dependent on the underlying persistence mechanism's guarantees - what ships by default is the SleepyCat Db configuration set such that it persists to disk on Commit.

Good points wrt pluggable persistence. Its something that's been discussed often and fairly easy to implement - in that the implementation is factored out so as to be able to easily use another persistence API instead of the default SleepyCat persistence API. Its on the long-term roadmap.
If you are working off open code, then there are several interfaces that need to be implemented plus one needs to be well versed with the object DNA format DSO uses - so I'd also add a word of caution that it is not a trivial undertaking.

Hope this is useful. If it helps, send me a PM and we could chat/email some more to discuss your app and if there are workarounds for some of the product gaps we've highlighted in this exchange...
Regards
Iyer.

Thanks for the detailed post. You seem to have thought through several of the issues involved.

You are correct - there is no support for asycnhronous replication across the WAN currently. Some folks we have talked to, either have a single pair of Terracotta servers if the data-centers are close by (<20 miles, where the WAN latencies are not significant) or follow a similar clustering topology as you've indicated - a cluster with a pair of H/A Terracotta servers (in persistence mode) local to each data-center.

What is missing as of version 2.2, is the asynchronous replication of this data to a backup data-center (or the central cluster in your case) and the pluggable conflict resolution mechanism that your application is interested in.

We have played around with the log-based replication (such as using the capabilities that come with BerkelyDB/SleepyCat - which is the persistence mechanism Terracotta uses now), pushing changes from 1 sub-cluster to another via a persistent-q and other schemes, and some eventing to indicate conflict and custom resolution schemes, although nothing is set in stone yet.

We expect this to get resolved within a year or thereabouts, but it depends on the pull from the community...There is a separate JIRA now in the community project (https://jira.terracotta.org/jira/browse/CDV-28) - perhaps folks could vote on it to indicate interest.

Lmk if we can provide additional clarification...
cheers
iyer.