Clojure
Rich Hickey discusses Clojure features and syntax, example code, functional programming, concurrency semantics, transactions, software transactional memory, agents, implementation and pain points.
- Java,
Tracking change and innovation in the enterprise software development community
Posted by Gavin Terrill on Aug 28, 2008 04:49 PM
Greg Luck, of the EhCache team, announced in early August the availability of SOAP and RESTful APIs for caching. As described in the documentation:
Ehcache now comes with a Cache Server, available as a WAR for most web containers, or as a standalone server. The Cache Server has two APIs: RESTful resource oriented, and SOAP. Both support clients in any programming language.
In a follow up post, Greg outlines his thoughts on deployment options for a theoretical 1 terabyte cache:
The largest ehcache single instances run at around 20GB in memory. The largest disk stores run at 100Gb each. Add nodes together, with cache data partitioned across them, to get larger sizes. 50 nodes at 20GB gets you to 1 Terabyte.
The first, and simplest, approach involves setting up several nodes running ehcache server and have the client determine the server to use based on an object's hashcode:
String[] cacheservers = new String[]{"cacheserver0.company.com", "cacheserver1.company.com", "cacheserver2.company.com", "cacheserver3.company.com", "cacheserver4.company.com", "cacheserver5.company.com"};
Object key = "123231";
int hash = Math.abs(key.hashCode());
int cacheserverIndex = hash % cacheservers.length;
String cacheserver =cacheservers[cacheserverIndex];
To support redundancy, a load balancer is introduced, and each node runs two ehcache server instances, with replication between them enabled using the existing distributed caching options (RMI or JGroups). In this approach, clients would still determine their servers using the hashcode, but now failures are handled transparently behind the virtual IP assigned by the load balancer.
The third option Greg describes involves moving the responsibility for routing requests to the load balancer.
The RESTful version of the EhCache Server is based on Jersey - the JSR 311 reference implementation. Paul Sandoz, one of the Jersey developers, discussed how the client API of jersey could be used to access the cache for creating and retrieving a sample XML document:
// retrieving a node
Node n = r.accept("application/xml").get(DOMSource.class).getNode();
// creating a node
String xmlDocument = "...";
Client c = Client.create();
WebResource r = c.resource(http://localhost:8080/ehcache/rest/sampleCache2/2);
r.type("application/xml").put(xmlDocument);
So, in what scenarios would a RESTful cache be useful? James Webster reports on seeing an increase in adoption of this architectural style in large enterprises:
An architectural pattern that I have observed a few investment banks implement is a distributed memory cache accessed via a RESTful front-end over HTTP for providing access to market data (e.g.. stock prices, interest rate curves, or derived values like volatility surfaces & correlations) and static data (e.g. counterparty details, settlement defaults). The distributed cache can be ‘easily’ scaled to hold massive data sets and the front-end allows the data to be accessed in a technology agnostic fashion, as long as the client can speak HTTP.
As James points out, it will be interesting to see how long it will take commercial vendors (such as Oracle and Gigaspaces) to support RESTful interfaces in their products.
Hibernate without Database Bottlenecks
Terracotta Distributed Cache Performance Case Study
Gnip Case Study: Reliable and Scalable Access to Massive Data Streams from Multiple Sources
int hash = Math.abs(key.hashCode());
is not always positive.
www.blogger.com/comment.g?blogID=33967480&p...
Why would venders like Oracle or Gigaspaces want to expose caching via SOAP or REST? Caching is not a service; exposing such a 'service' enterprise wide would only lead to problems down the road.
Best Regards,
Richard L. Burton III
They are not saying that caching would be provided as a service by Oracle or Gigaspaces. They are merely pointing out that the services that are provided by these vendors might have RESTful APIs for their clients, in the future. RTFA!
Carlos
Caching is not a service
Mark Nottingham's "Leveraging the Web for Services at Yahoo!" talk (QCon London 2007) challenged my idea of what caching could be used for. He explains how HTTP-based caching using Squid has been used to integrate the many Yahoo! properties.exposing such a 'service' enterprise wide would only lead to problems down the road
I'd be interested in hearing about the problems you foresee.
I second Gavin's request - what's wrong with caching as a service?
Rich Hickey discusses Clojure features and syntax, example code, functional programming, concurrency semantics, transactions, software transactional memory, agents, implementation and pain points.
We introduce the concept of Composite Oriented Programming, and show how it avoids the issues with OOP and reignites the hope of being able to compose domain models with reusable pieces.
Dan Farino talks about the system architecture and the challenges faced when building a very large online community. Dan explains how a .NET product scales on hundreds of servers.
Alan Shalloway, CEO and founder of Net Objectives, presents the Lean software development principles and practices and how they can benefit to Agile practitioners.
Bernd Mathiske discusses Maxine VM, Java compatibility, swapping major VM components, research areas, Object handling, code examples, optimizing compiler, snippets, bytecode generation, JNI and JIT.
Joe Armstrong speaks on various aspects of the Erlang language, presenting its roots, how it compares with other languages and why it has become popular these days.
The java double-check singleton pattern is not thread safe and can’t be fixed. In this article, Dr. Alexey Yakubovich provides an implementation of the Singleton pattern that he claims is thread-safe.
Diana and Jim talk about patterns observed in CTOs' activity. CTOs emerge as real people caring for other people in their organization, and are put under a lot of pressure and constraints.
6 comments
Reply