Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jsf linkedin maven montana roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« Lots of Java activit... | Main | Are you doing client... »
Wednesday November 23, 2005

Clustering OSCache

For the past few days, I've been tuning and configuring OSCache in a clustered (WebLogic) environment. While setting it up was fairly easy, there was some fundamental concepts that took me a bit to figure out.

First of all, I chose to use JavaGroups instead of JMS. The primary reason behind this was it was easier to configure, but I also discovered that if you use JMS - you have to have a unique "cache.cluster.jms.node.name" property in your oscache.properties file on each server. This means to use OSCache with JMS, you have to build two different EARs. At least that's my impression. If you've figured out a better way to do this, please let me know.

In the application I'm working on, there are 4 different caches: one for Hibernate, and several other ones we've created with OSCache and Spring. For the past week, I developed a feature where we cache a user's account information across the cluster. The feature is more like an HttpSession than a cache b/c it's designed to replicate an authentication token (similar to a session id) across all the master servers.

After much head pounding, I discovered that OSCache doesn't update other nodes in a cluster for inserts and updates. It only broadcasts flushes. After understanding how OSCache works, it was much easier for me to code the solution (sans OSCache). If you'd like to see OSCache support replicating a cache across a cluster, vote for CACHE-96.

Posted in Java at Nov 23 2005, 01:05:44 PM MST 9 Comments
Comments:

What cache did you finally use?

Posted by 82.182.214.87 on November 23, 2005 at 04:16 PM MST #

We're still using OSCache, we just understand it's limitations now. For the feature I needed inserts and updates for - I just wrote a workaround to transparently re-authenticate the user if their authentication token is not found on the current server. It's a hack, but it works. I realize we could use Coherence for a replicated caching engine.

Posted by Matt Raible on November 23, 2005 at 08:53 PM MST #

Wow...caching alogorithm...now I am impressed. Hmm I think I know a cool open source project that can use this kind of expertise ;-)

Posted by Jeff Genender on November 23, 2005 at 09:15 PM MST #

Matt - thats one of the reasons why OSCache is so fast, its not slowing down your network replicating everything to every node. It is each nodes own responsibility to populate itself, the only "shared thing" between nodes is the cache invalidation, which would clear the same data on any node that stored it (or so I understand). If you use JMS with OSCache, don't you need to add a JMS server? doesn't this then become a SPOF? which pretty much invalidates the point of clustered replication anyway... you don't get that problem with javagroups. If you are looking for a painless (and free) cache solution that supports clustered replication, look at memcached. Although this not a java solution, its a C app, that has a java API available. Coherence is definately the way to go, if you can afford it!

Posted by Lee on November 24, 2005 at 05:07 AM MST #

I'll second memcached as being a nice solution to the distributed cache problem. I have not used coherence, but it seemed interesting. Not sure when coherence is advantageous (?)...since memcached has done everything I've asked of it...

Posted by ian on November 24, 2005 at 07:59 PM MST #

I have not used coherence, but it seemed interesting. <p/> You can download an eval from tangosol.com. It's a commercial product, but the eval license is a free download and the development license (including support) is also no-charge, with the prices all published for production licensing. <p/> Not sure when coherence is advantageous (?)...since memcached has done everything I've asked of it... <p/> Coherence was around before memcached, so the question is a bit backwards ;-) <p/> Coherence isn't just used for content caching. It is a data management system that can scale out to hundreds of servers and can manage many gigabytes of data without any single points of failure. Basically, you throw data into it and it's there, regardless of whether you add or remove servers (or they accidentally die). You have transactions, query capabilities, parallel grid processing, JMX, near caching, NIO overflow, etc. It's pure Java, and serves as the backbone for a number of exchanges, trading systems, travel systems, logistics systems .. and of course a lot of very busy websites. <p/> Peace.

Posted by Cameron Purdy on November 24, 2005 at 09:25 PM MST #

I had exactly the same problems with JMS and JavaGroups. I have solved this by implementing my own plugins so that I didn't have to patch OsCache. For JMS I used a GUID as node name and for JavaGroups I implemented the other events as well and made them configurable. I haven't donated them back to OsCache yet, but if you are interested in the solution I can send you the code.

Posted by Rintcius Blok on December 07, 2005 at 08:22 AM MST #

As far as the multiple ear problem goes, could you setup a URL provider that points to the different properties files and then reference the correct one thru JNDI / references?

Posted by Bill Davis on December 07, 2005 at 10:53 AM MST #

Hmmm...While we are talking about distributed caching solutions, I have some experience on the topic. I must confess, I have primarily worked on .NET caches but there are some which have the potential to work on multiple frameworks. For example, for the last couple of years, I have been using NCache which has all the features of a real .NET enterprise caching solution and also has a Java plug-in without the need of an inter-operatability bridge.

Caching has solved a lot of my performance and scalability needs but the best thing that I feel it has done for my mission critical app is iron-clad reliability. With us going into GRID computing pretty soon, it would prove to be one of the best investments our company has made in a long time.

Thanks.

Posted by Joe Cohen on January 11, 2010 at 01:57 PM MST #

Post a Comment:
  • HTML Syntax: Allowed