[infinispan-dev] Infinispan within JBossAS

Tue May 4 07:10:51 EDT 2010

Thanks Manik and Galder,

I'll come back to you if I have more questions...

/Dimitris

galder at jboss.org wrote:
> Hi Dimitris,
> 
> See inline:
> 
> ----- "Manik Surtani" <manik at jboss.org> wrote:
> 
>> On 29 Apr 2010, at 19:00, Dimitris Andreadis wrote:
>>
>>> Hi guys,
>>>
>>> I'll be doing a short talk about JBoss 6 & Infinispan at a local
>> conference:
>>> "This presentation introduces Infinispan, the new underlying data
>> caching and replication 
>>> infrastructure included with the upcoming JBoss AS 6. Infinispan is
>> an Open Source library 
>>> that can be used independently of JBoss AS to let you build dynamic
>> and highly available 
>>> data grids that scale to the order of thousands, while offering a
>> large number of enterprise 
>>> features."
>>>
>>> I need some help to identify the key benefits of using Infinispan in
>> the context of AS.
>>> - Why is it going to be better from JBoss Cache?
>>> - What are the major use cases we are addressing?
>> From a JBossAS perspective (for now at least) I believe it is all of
>> the same stuff JBoss Cache did: EJB and HTTP session replication, JPA
>> 2nd Level Cache.
>>
>>> The obvious ones are
>>>
>>> - smaller memory footprint
>>> - faster
>> Both of the above, but also greater scalability (larger clusters),
>> lower overhead when new nodes join existing clusters (--> faster
>> startup)
>>
>>> But I need more, in terms of how it will affect
>>>
>>> - session/sfsb replication
>>> - jpa/entity caching invalidation, 2nd level caching
>> Nothing new in terms of "features" (over what JBoss Cache offered),
>> except perhaps finer grained control over eviction settings for the
>> JPA 2nd Level Cache.  Galder can comment more here.
> 
> The biggest internal change 2nd level caching is that each entity/collection type is stored in its own lightweight cache instance. Before with JBoss Cache, all entity/collections shared the same cache instance. As Manik hinted, the most visible change from a user perspective is that you can define eviction settings or a per entity/collection type much more easily than you could with JBoss Cache based 2nd level cache. Before, you needed to know the internal JBoss Cache tree structure to be able to define these correctly and you needed to modify the actual JBoss Cache configuration file. With Infinispan, no need to modify infinispan configuration any more, you can define evictions directly in your hibernate/ejb3 descriptor and the actual configuration is much more intuitive:
> 
> http://community.jboss.org/wiki/usinginfinispanasjpahibernatesecondlevelcacheprovider#Advanced_Configuration
> 
>>> - other?
>> The ability for people to use a data grid directly, in their
>> applications, as an alternative data store.
>>
>>> Beyond the "standard" usage of Infinispan replacing JBossCache in
>> AS, I need usecases of 
>>> datagrids used in the context of AS deployments. Is it going to be
>> used primarily as a 
>>> read-mostly cache? Do you have some examples?
>> Some typical scenarios would be to front "expensive" data stores, web
>> services, etc., in which case you are looking at a read-mostly cache. 
>> But other use cases also include a complete datastore replacement. 
>> Fast, scalable, transactional, in-memory durable datastore.
>>
>>> I'm trying to imagine applications that would really benefit by the
>> JBossAS/Infinispan 
>>> combination when deployed in the cloud in really large numbers (e.g.
>> hundred of AS 
>>> instances). Would a special architecture design would need to be
>> used in this case?
>>
>> Depends on the level if durability expected.  For example, tuning your
>> cache store for overflow/persistence is one area where you can
>> exercise the tradeoff between performance and durability.  Sync or
>> async network communications come into play as well.
>>
>>> Finally, do you have some standalone Infinispan usage examples?
>> Yes - a lot of what I have seen involve grid-based applications that
>> farm out tasks to a grid of processor nodes that also need access to
>> data.  Traditional data stores become bottlenecks very quickly in such
>> cases, so storing data in a distributed fashion is key.  Having data
>> locality and storing stuff in memory (low latency) are added pluses. 
>>
>>
>>> I think it will be great if we can associate/match Infinispan
>> (within AS) to real people 
>>> problems and usecases.
>> It will primarily centre around scalability/fast, low-latency data
>> access.  There will also be the ability to stack "tiers" of data grids
>> with the client/server stuff we're doing.  So this gives you access to
>> large amounts of storage space.  
>>
>> And cloud-scale deployments, where you need fast startup regardless of
>> cluster size, elastic scale out/scale in, etc.  Here is a quick
>> diagram I pieced together some time back, for a "stateless" app server
>> (which will be necessary to achieve app server elasticity).  Note that
>> this is just a concept, hasn't been decided upon that this will happen
>> in JBoss AS yet, etc.
>>
>>
>>
>> [image/png:StatelessAppServer.png]
>>
>>
>>
>> HTH
>> Manik
>>
>>> Thanks for the help!
>>>
>>> /Dimitris
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> ------------------------------------------------------------------------
>>