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.

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