[infinispan-dev] keySet(), values() and entrySet() impl progress and some questions

Mircea Markus mircea.markus at jboss.com
Tue Jun 9 11:24:38 EDT 2009


Galder Zamarreno wrote:
> Hi all,
>
> I'm making good progress with 
> https://jira.jboss.org/jira/browse/ISPN-94. I'm currently testing that 
> with DIST mode, only local contents are returned.
>
> We had agreed that these operations should not be participating in 
> transactions and I assume that this is so that locks are not acquired. 
> From what I understand, to achieve this, CacheDelegate method 
> implementation would need to pass a 
> icc.createNonTxInvocationContext(), correct?
yes. I've just seen that size() is not doing that (it is using 
icc.createInvocationContext); as you're in the scope, can you please 
amend that as well
>
> We also agreed that we needed to document the limitations in javadoc 
> but in which javadoc? Obviously, Map javadoc cannot be touched, so I 
> suppose we should redefine the ops in the Cache interface and document 
> them there, correct?
>
> Finally, one note about the MVI. As per an IRC conversation with 
> Manik, the collections returned by these methods need to be modified 
> so that marshalled values are swapped by real values. The collections 
> returned by these methods are not currently ready to be mutable so 
> instead I've gone for the copying option changing the marshalled 
> values to the real objects.
>
> I've taken this decision because:
> - The implementation was simpler by just copying.
> - Not sure there's much point in implementing mutable collections for 
> the return of these methods if we're only gonna need to mutate them 
> for the marshalled value edge case. The one advantage of mutable 
> collections would be the ability to swap the marshalled values 
> directly without copying, hence memory consumption would less.
> - Remember that these collection returning methods should primarily 
> used for debugging and not for production, hence the extra memory 
> consumption for these type of methods doesn't sound like such a bad 
> thing.
>
> Thoughts?




More information about the infinispan-dev mailing list