[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