Navigation

RSS 2.0 New Entries Syndication Feed Atom 0.3 New Entries Syndication Feed

Show blog menu v

 

General

Use it

Documentation

Support

Sibling projects

RIFE powered

Valid XHTML 1.0 Transitional

Valid CSS!

Blogs : Latest entries

< Previous page 
The sanitization of Ehcache's Cache constructors

We've all been there, you start with a class and a simple constructor that makes total sense. As time goes by, you keep adding features and the list of constructor arguments grows … and grows … until … it becomes unusable. This is exactly what happened with the Cache class in Ehcache.

The version 1.0 constructor looked like this:

public Cache(String name, int maxElementsInMemory, 
             boolean overflowToDisk, boolean eternal, 
             long timeToLiveSeconds, long timeToIdleSeconds)

However, with version 1.7 this turned into:

public Cache(String name, int maxElementsInMemory,
             MemoryStoreEvictionPolicy memoryStoreEvictionPolicy, 
             boolean overflowToDisk, String diskStorePath, 
             boolean eternal, long timeToLiveSeconds,
             long timeToIdleSeconds, boolean diskPersistent, 
             long diskExpiryThreadIntervalSeconds, 
             RegisteredEventListeners registeredEventListeners, 
             BootstrapCacheLoader bootstrapCacheLoader,
             int maxElementsOnDisk, int diskSpoolBufferSizeMB, 
             boolean clearOnFlush,
             boolean isTerracottaClustered,
             String terracottaValueMode, 
             boolean terracottaCoherentReads)

There are a lot of downsides to relying on constructor parameters like this:

  • the author of the class needs to continue to overload the constructors to add new parameters
  • users need to decide which overloaded constructor they want to use
  • users need to figure out what sensible default values are for the values that they're not interested in
  • it's very easy to accidentally put a value at the wrong place and provide wrong parameters
  • reading the constructor afterwards is a nightmare and can't be done without looking at the Javadocs at the same time, for instance:
new Cache("myCache", 10000, MemoryStoreEvictionPolicy.LRU, false, 
          null, true, 60, 30, false, 0, null, null, 0, 0, false, 
          true, "identity", true)

However there some advantages:

  • you can enforce which parameters are mandatory
  • at instantiation you can validate the constructor parameters
  • at instantiation you fully set up the instance without requiring users to call an initialization method

So, we decided to change the Cache constructor approach in Ehcache 2.0 and use a builder pattern with a fluent interface, keeping the advantages of the parameters approach but solving all the problems.

The version 2.0 constructor looks like this:

new Cache(CacheConfiguration config)

We then created a constructor in CacheConfigurator with the strict minimal number of parameters that are required for a cache to function:

public CacheConfiguration(String name, int maxElementsInMemory)

All the other parameters are implemented as fluent interface methods as well as regular setters and getters so that instances of the class can be used as beans:

public final CacheConfiguration clearOnFlush(boolean clearOnFlush) {
  setClearOnFlush(clearOnFlush);
  return this;
}

This allows the example above to be rewritten like this:

new Cache(new CacheConfiguration("myCache", 10000)
      .eternal(true)
      .timeToLiveSeconds(60)
      .timeToIdleSeconds(30)
      .terracotta(new TerracottaConfiguration()
          .clustered(true)
          .valueMode(ValueMode.IDENTITY)));

The end results are that:

  • we can continue to expand the CacheConfiguration class without ever having to change the constructors of the Cache class
  • the user doesn't have to figure out the defaults for parameters he doesn't care about
  • the configuration parameters are self-explanatory by simply looking at the available API methods
  • anyone can read the usage of any Cache constructor and understand what each configuration value's purpose is
posted by Geert Bevin in Ehcache on Feb 17, 2010 6:34 PM : 7 comments [permalink]
 
Fix for slower startup and shutdown times since Snow Leopard 10.6.1

Ever since I upgraded to Snow Leopard 10.6.1, my MacBook Pro startup and shutdown was much slower than before.

I searched for a quite a while on forums to find the solution, but nobody seemed to know a solution. I finally figured out what it was. It seems that somehow the ownership of my startup volume's root directory (/) wasn't assigned to the root account anymore, but to my account instead. This made the kernel prelinking fail since it requires that root is the owner.

This is how you solve this after launching the Terminal app:

sudo chown root:admin /
sudo kextcache -system-prelinked-kernel
sudo kextcache -system-caches

You'll have to enter your password after the first command.

Hope this helps someone, since it was really frustrating to have these slower startup/shutdown times for me.

posted by Geert Bevin in MacOSX on Sep 20, 2009 11:09 PM : 30 comments [permalink]
 
Terracotta 3.1: Introduction to Examinator

Terracotta 3.1GA was released a few days ago and sports some interesting new features that are specifically geared towards clustering Hibernate second level caches.

I decided to create a series of video tutorials and presentations about Terracotta's new clustered caching capabilities and will demonstrate most of this from our Examinator reference application.

The first video highlights how to install, setup and use Examinator as a basis for the next videos.

Enjoy!

posted by Geert Bevin in Terracotta on Aug 27, 2009 7:16 PM : 0 comments [permalink]
 
My first YouTube video : Robert Plant cover song

I picked music back up after a loooong hiatus of 7 years. I decided to evolve together with the world and to broadcast myself ;).

Did the first one last night. The song is "All The Kings Horses" from Robert Plant and the Strange Sensation. When I heard it playing last afternoon from my iTunes collection, I couldn't help picking up my guitar to figure out the chords and such. This recording is the result of a couple of hours searching and rehearsing. I'm considering adding it to a concert repertoire I'm preparing, as one of the few cover songs.

Anyways, my YouTube channel is located at http://www.youtube.com/gbevin and I'll be posting new entries as I learn and compose songs.

Hope you enjoy it, and if you don't, still be nice :)

posted by Geert Bevin in Music on Aug 27, 2009 7:16 PM : 2 comments [permalink]
 
How do you use Hibernate Extended Sessions?

The Open Session in View pattern is very popular when Hibernate is used in a web application. This allows you to safely use managed entities when your view is being rendered. At Terracotta, we're currently researching what other patterns are popular for Hibernate and how people apply them.

One that I'm in particular looking into is the Extended Session pattern for long running conversations. This allows you to disconnect a Hibernate session in between requests and to store it in the HTTP session in the meantime.

I'd like to know who's using the extended session pattern and what you use it for.

To understand more about this, I developed a small example application to get a feel for the advantages, the benefits, the gotchas and the surprises. The application can be found below, it is inspired by snippets from Hibernate tutorials and example applications:

http://svn.terracotta.org/svn/forge/projects/hibernate-disconnected/trunk/

The example uses only servlets, filters and Hibernate. It is a webapp that allows you to create events and add people to it over different requests. When an event has been created with all the relevant people, it can be committed in one step. The intermediate state is kept within the managed entities and the Hibernate session until it's flushed.

This is what I found worth mentioning:

  • Whenever a transaction is created and committed, it doesn't matter if Hibernate flush mode is set to manual, certain operations like persist and merge will be propagated to the database at transaction commit. However, modifications to managed entities wont be committed, this can be confusing.
  • Even with manually flushed sessions, transactions are always real database transactions, causing locks to be held. They thus need to be as short as possible.
  • A single general-purpose servlet filter might not be feasible, depending on how transactions should behave. In this application, I ended up creating only a transaction around the actual session flush.
  • Data that is present in a manually flushed session buffer is batched but not available for queries.
  • This doesn't behave the same as a database transaction with isolation levels that can still see their own changes.
  • If the data needs to be available for a query, a commit needs to happen first.
  • This can require application changes, like a redirect after form submission in case transactions are automatically committed through a servlet filter.

Totally unrelated but cool, you can use an AnnotationConfiguration class to setup the Hibernate config and use a fluent interface to add the managed entity classes. This reduces the amount of XML and eases maintenance (see HibernateUtil class in my example).

posted by Geert Bevin in Java on Apr 16, 2009 3:53 PM : 4 comments [permalink]
 

< Previous page 
 
 
 
Google
rifers.org web