-- Devoxx last day, I only slept 2 hours during the previous night. Need I really say more? --
Clustering your applications with Hazelcast by Talip Ozturk
Hazelcast is an OpenSource product used by many companies (even Apple!).
HashMap is a no-thread safe key-value implementation. If you need thread safety, you’ll use
ConcurrencyHashMap. When you need to distribute your map against distributed JVMs, you use
Hazel.getMap() but the rest is the same as for the
Map interface (but not interface itself).
-- a demo is presented during the entire session --
Hazelcast let you add nodes very easily, basically just by starting another node (and it takes care of broadcasting).
Hazelcast alternatives include Terracotta, Infinispan and a bunch of others. However, it has some unique features: for example, it’s lightweight (1,7 Mb) without any dependency. The goal is to make distributed computing very easy.
In a Hazelcast cluster, there’s a master, but every node knows the topology of the cluster so that when the master eventually dies, its responibilities can be reassigned. Data is backed up on other nodes. Typical Hazelcast topology include data nodes and lite members, which do not carry data.
Enterprise edition of Hazelcast is the Community Edition plus Elastic Memory configuration and JAAS Security. It’s easy to use Hazelcast in tests with the
Hazelcast.newHazelcastInstance(config) statement. Besides, an API is available to query about the topology. Locking is either done globally on the cluster or on a single key. Finally, messaging is also supported, though not through the JMS API (note that messages aren’t persistent). A whole event-based API is available to listen to events related to Hazelcast.
A limitation of Hazelcast is that objects put into it have to serializable. Moreover, if an object is taken from Hazelcast and then modified, you have to put it back into Hazelcast so that it’s also updated inside the cluster.
Hazelcast doesn’t persist anything, but ease the task of doing it on your own through the
MapLoader. There are two ways to store: write-behind which is asynchronous and write-through which is synchronous. Reads are read-through which is basically lazy-loading.
About long GC-pauses:
Killing a node is good, but letting it hang around like a zombie is not
mgwt - GWT goes mobile by Daniel Kurka
The speaker’s experience has taught him that mobile apps are fated to die. In fact, he has used and developed many mobile applications. The problem, is that you’re either limited by a too small number of applications, or the boundary goes higher and you cannot find them anymore. In the past, Yahoo put web pages into a catalog, while Google only crawled and ranked them. App stores looks like crap, they don’t provide a way to search for applications you’re itnerested in. Besides, when you’re looking for public transports schedule, you have to install the application of the specific company. Worse, some sites force you to install the application instead of providing the needed data.
- Startup performance, a matter of downloading, parsing, executing and rendering
Both are taken into account by the GWT compiler. Note that mgwt provides plenty of themes, one for each mobile platform.
-- And now ends Devoxx 2012 edition for me. It was enriching as well as tiring. You can find the recap of the previous days here: