[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