[DIRECTMEMORY-62] Adopt fluent APIs for bootstrapping the Cache (and optionally manage stored objects)

• Type: New Feature
• Status: Resolved
• Priority: Major
• Resolution: Won't Fix
• Affects Version/s: 0.1-incubating
• Fix Version/s: 0.1-incubating
• Assignee: Simone Tripodi
• Reporter: Simone Tripodi
• Created: 18/Feb/12 23:06
• Updated: 26/Feb/12 11:56
• Resolved: 26/Feb/12 00:13

Description

Hi all guys,

as discussed some days ago, I started prototyping an EDSL embedded in DM to make Cache APIs more "sexy"

So, influenced by the past experience with Commons Digester - influenced by Google Guice - I tried to identify the 2 phases in the Cache lifecycle

• the "bootstrap" phase - where settings are used to instantiate the Cache;

• the object store management.

Current codebase has a mix of both and users have to be aware of correct sequence of operations call, I mean, calling Cache.retrieve( "aaa" ) without having previously called Cache.init( 1, Ram.Mb( 100 ) ) at the beginning of the program, would cause an error. That is why I recurred to a kind of "configuration" pattern to make sure Cache instance have to be configured first and then can be used:

        /* Basic configuration APIs */
        Cache cache = DirectMemory.createNewInstance( new CacheConfiguration()
        {

            @Override
            public void configure( CacheConfigurator cacheConfigurator )
            {
                cacheConfigurator.numberOfBuffers().ofSize( 1 );
                cacheConfigurator.allocateMemoryOfSize( 128 ).Mb();
                cacheConfigurator.scheduleDisposalEvery( 10 ).hours();

                cacheConfigurator.bindConcurrentMap().withJVMConcurrentMap();
                cacheConfigurator.bindMemoryManagerService().withDefaultImplamentation();
                cacheConfigurator.bindSerializer().fromServiceProviderInterface();
            }

        } );

Hoping that the code itself is clear enough, the DirectMemory class accepts a CacheConfiguration, users have to override the {{ configure( CacheConfigurator )}} method, where describing the basic Cache behavior, and will return a Cache instance.

According to the DRY (Don't Repeat Yourself) principle, repeating "cacheConfigurator" over and over for each binding can get a little tedious, so there is an abstract support class:

        cache = DirectMemory.createNewInstance( new AbstractCacheConfiguration()
        {

            @Override
            protected void configure()
            {
                numberOfBuffers().ofSize( 1 );
                allocateMemoryOfSize( 128 ).Mb();
                scheduleDisposalEvery( 10 ).hours();

                bindConcurrentMap().withJVMConcurrentMap();
                bindMemoryManagerService().withDefaultImplamentation();
                bindSerializer().fromServiceProviderInterface();
            }

        } );

Once obtained the Cache instance, users can now start storing objects:

        Pointer a = cache.allocatePointer( 1 ).Gb().identifiedBy( "Simo" );
        Pointer b = cache.put( "Strored!" ).identifiedBy( "Raf" ).thatNeverExpires();
        Pointer c = cache.putByteArray( new byte[0] ).identifiedBy( "Izio" ).thatExpiresIn( 1 ).days();

        Pointer d = cache.update( new Object() ).identifiedBy( "Olivier" );
        Pointer e = cache.updateByteArray( new byte[0] ).identifiedBy( "TomNaso" );

WDYT?