[infinispan-issues] [JBoss JIRA] (ISPN-1678) A simple GET operation during a transaction or batching creates the NonTxInvocationContext instead of the more efficient SingleKeyNonTxInvocationContext
Sanne Grinovero (JIRA)
jira-events at lists.jboss.org
Mon Jan 16 14:48:18 EST 2012
[ https://issues.jboss.org/browse/ISPN-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanne Grinovero updated ISPN-1678:
----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/842 (was: https://github.com/infinispan/infinispan/pull/842)
Description:
Doing a simple get, generates this stack:
org.infinispan.CacheImpl.get(Object)
org.infinispan.CacheImpl.get(Object, EnumSet<Flag>, ClassLoader)
org.infinispan.CacheImpl.getInvocationContextForRead(Transaction, EnumSet<Flag>, ClassLoader, int) <-------------- int = 1
org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(boolean, int) <------------------ false, 1
org.infinispan.context.TransactionalInvocationContextContainer.newNonTxInvocationContext(boolean) <------------------ true
At this point the information of this being a simple get - hence operating on a single key - is lost, and we end up generating a NonTxInvocationContext, which initializes an HashMap in it's constructor...
I'd like this use case to actually use org.infinispan.context.SingleKeyNonTxInvocationContext
was:
Doing a simple get, generates this stack:
org.infinispan.CacheImpl.get(Object)
org.infinispan.CacheImpl.get(Object, EnumSet<Flag>, ClassLoader)
org.infinispan.CacheImpl.getInvocationContextForRead(Transaction, EnumSet<Flag>, ClassLoader, int) <-------------- int = 1
org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(boolean, int) <------------------ false, 1
org.infinispan.context.TransactionalInvocationContextContainer.newNonTxInvocationContext(boolean) <------------------ true
At this point the information if this being a simple get - hence operating on a single key - is lost, and we end up generating a NonTxInvocationContext, which initializes an HashMap in it's constructor...
I'd like this use case to actually use org.infinispan.context.SingleKeyNonTxInvocationContext
> A simple GET operation during a transaction or batching creates the NonTxInvocationContext instead of the more efficient SingleKeyNonTxInvocationContext
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-1678
> URL: https://issues.jboss.org/browse/ISPN-1678
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core API
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Fix For: 5.1.0.FINAL
>
>
> Doing a simple get, generates this stack:
> org.infinispan.CacheImpl.get(Object)
> org.infinispan.CacheImpl.get(Object, EnumSet<Flag>, ClassLoader)
> org.infinispan.CacheImpl.getInvocationContextForRead(Transaction, EnumSet<Flag>, ClassLoader, int) <-------------- int = 1
> org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(boolean, int) <------------------ false, 1
> org.infinispan.context.TransactionalInvocationContextContainer.newNonTxInvocationContext(boolean) <------------------ true
> At this point the information of this being a simple get - hence operating on a single key - is lost, and we end up generating a NonTxInvocationContext, which initializes an HashMap in it's constructor...
> I'd like this use case to actually use org.infinispan.context.SingleKeyNonTxInvocationContext
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list