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
I am no expect at all of the code base.
Wouldn't returning LocalCacheImpl happening in very very specific cases and
thus not be of quite limited use?
And that resonates with the discussion of splitting the interceptor logic into
before and after methods. And keeping the state not in the
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
BTW, a generic interface based call to interceptors is hard to optimize by the
VM AFAIU.
So having a few specialized implementations of CacheImpl that do hard code the
calls to specific interceptor implementations (the 2 methods split ones) would
make a lot of sense to me for a handful of
+1 I'd love to see an evolution like that, I guess there should be
various use cases which benefit from having no interceptor stack at
all.
As I see it, implementing the same Cache API as Infinispan would be
nice but not necessary, assuming you don't need all of the same
features.
Mildly
Pushing the idea further, you can actually make the CacheImpl specifically
tailored to the configuration of a given cache by using ASM or anything that
lets you build a class at runtime.
That way, in this specialized implementation, all the interceptorImpl.before()
and interceptorImpl.after()
@ 'very very specific cases': yes, given the plethora of options
Infinispan gives you, it is specific. However that does not say that
these use cases are not the most common.
I don't think this has really too much common with the interceptor stack
rework discussion - there the move is from
Ah. Tristan told me these plans are already in motion in stages.
On 22 juin 2015, at 08:09, Emmanuel Bernard emman...@hibernate.org wrote:
Pushing the idea further, you can actually make the CacheImpl specifically
tailored to the configuration of a given cache by using ASM or anything that
