Question I pose to all of this is seeing the word user, which i think needs to
be asked.
What are you seeing DirectMemory as, a CacheStore which is the OffHeapStore
(which is what terracottas own big memory is to EHCache) which you can plug
into existing Cache Frameworks,, which the project provides the modules to plug
into such frameworks as JCR, JCache, OSCache, EHCache etc or are you trying to
write a cahce framework from scratch?
If its a CacheStore then really i think each plugin module such as im starting
to write for EHCache and Mir is writing for JCR is where the configuration
style and method sit etc, as long as developers writing the plugins know how to
interact with the cache then that should be enough. User will use the
frameworks already existing for configuration and these are well documented in
those projects.
If we're trying to write yet another Caching Framework, i don't personally see
the point, there are all ready good frameworks out there, and your better off
concentrating on the actual improvements of the OffHeap store, e.g. bugs,
speed, sizing needed on heap, concurrency etc.
Mike
On 19 Feb 2012, at 00:43, Daniel Manzke wrote:
> Hey guys,
>
> Simone asked me to write my 2 cents for it. ;)
>
> Due to the fact, I had a lot to do with Simone and Guice, I just can say
> that I also really like fluent apis. But reading this apis feels like
> trying to use fluent, where it doesn't fit.
>
> I often have problems with fluent apis, which have really long names for
> the method, because without them, it is not clear what they are doing.
> (because to complex?!)
>
> {code}
> /* Basic configuration APIs */
> Cache cache = DirectMemory.createNewInstance( new
> CacheConfiguration()
> {
>
> @Override
> public void configure( CacheConfigurator cacheConfigurator )
> {
> cacheConfigurator.buffers().count( 1 );
> cacheConfigurator.allocate(MemoryUnit); //(or what was your
> class? ram?)
> cacheConfigurator.dispose().every(TimeUnit);
>
> cacheConfigurator.bind(Map.class).to(..); //use guice ESDL -
> Default Implementations should
>
> //never
> have to be bound manually ;)
> cacheConfigurator.bind(MemoryManager.class).to(..);
> cacheConfigurator.bind(Serializer.class).to(..);
> }
>
> } );
> {code}
>
> {code}
> Pointer a = cache.allocatePointer( 1 ).Gb().identifiedBy( "Simo" );
> Pointer b = cache.put( "Strored!" ).identifiedBy( "Raf" ); //expiring
> depends on the default of the cacheConfiguration
> Pointer b2 = cache.put( "Strored!" ).identifiedBy( "Raf"
> ).expires().in(TimeUnit);
>
> Pointer d = cache.update( new Object() ).identifiedBy( "Olivier" );
> Pointer e = cache.updateByteArray( new byte[0] ).identifiedBy(
> "TomNaso" )
> {code}
>
>
> Do you really have a put and putByteArray? That's hard. ;) And for my
> cases, I would add a putStream(..)? :)
>
> (we have created a cache implementation with focus on files/document cache
> (onheap, offheap, ...))
>
> 2012/2/19 Simone Tripodi (Created) (JIRA) <[email protected]>
>
>> Adopt fluent APIs for bootstrapping the Cache and manage stored objects
>> -----------------------------------------------------------------------
>>
>> Key: DIRECTMEMORY-62
>> URL: https://issues.apache.org/jira/browse/DIRECTMEMORY-62
>> Project: Apache DirectMemory
>> Issue Type: New Feature
>> Reporter: Simone Tripodi
>> Assignee: Simone Tripodi
>>
>>
>> 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:
>>
>> {code}
>> /* 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();
>> }
>>
>> } );
>> {code}
>>
>> 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:
>>
>> {code}
>> cache = DirectMemory.createNewInstance( new
>> AbstractCacheConfiguration()
>> {
>>
>> @Override
>> protected void configure()
>> {
>> numberOfBuffers().ofSize( 1 );
>> allocateMemoryOfSize( 128 ).Mb();
>> scheduleDisposalEvery( 10 ).hours();
>>
>> bindConcurrentMap().withJVMConcurrentMap();
>> bindMemoryManagerService().withDefaultImplamentation();
>> bindSerializer().fromServiceProviderInterface();
>> }
>>
>> } );
>> {code}
>>
>> Once obtained the Cache instance, users can now start storing objects:
>>
>> {code}
>> 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" );
>> {code}
>>
>> WDYT?
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA
>> administrators:
>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke
