[infinispan-dev] Interceptor stack for local caches

[Galder Zamarreno]

As Sanne suggested in another email, the minimum you'd need for a local non-JTA (e.g. only JDBC transactions) 2LC is the data container and the eviction part, e.g. LIRs. You could try to work something around those and see how far you get. 

Once you have JTA or clustering, you'd need more bells and whistles.

Cheers,

----- Original Message -----
> Hi,
> 
> few weeks ago I was looking into performance of local cache when
> compared to basic concurrent hash map, or data container. I can't find
> the exact results now, but the difference was in order of magnitude -
> IIRC concurrent hash map was about 20x faster than local cache. There
> was no 'bottleneck', but the versatile Infinispan design of commands
> traversing through interceptor stack brings some overhead (e.g.
> allocation costs with each invocation, not only for writes) while in
> some use cases it is not necessary to keep this complexity. The use case
> I am looking for is caching in Hibernate ORM, which basically requires
> only map with eviction, expiration and transactions in some cases. No
> need for cache stores, statistics etc. So far I've found ways to remove
> few interceptors [1], but it's few percent, not hundreds of percent
> where I would ideally aim.
> 
> Therefore, I was considering about an option to inspect cache
> configuration and in suitable cases return LocalCacheImpl that would get
> rid of the burden: no interceptor stack, no commands instantiation. This
> would be transparent to the user. I understand that it will increase
> maintenance costs, but it still seems better to me to have it under
> wings of Infinispan as caching solution rather than separate project, as
> it can share a lot of the codebase.
> 
> Do you think that this idea makes sense, or is it just too wild? Do you
> think I will crash when trying to implement this?
> 
> Radim
> 
> [1] https://issues.jboss.org/browse/ISPN-5542
> 
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>