Re: [infinispan-dev] About size()

>>>> Also we didn't really talk about the fact that these methods would >>>> ignore ongoing transactions and if that is a concern or not. >>>> >>> >>> It might be a concern for the Hibernate 2LC impl, it was their TCK that >>> prompted the last round of discussions about clear(). >> >> Although I wonder how much these methods are even used since they only >> work for Local, Replication or Invalidation caches in their current >> state (and didn't even use loaders until 6.0). > > > There is some more information about the test in the mailing list discussion > [1] > There's also a JIRA for clear() [2] > > I think 2LC almost never uses distribution, so size() being local-only > didn't matter, but making it non-tx could cause problems - at least for that > particular test. I had toyed around with the following idea before, but I never thought of it in the scope of the size method solely, but I have a solution that would work mostly for transactional caches. Essentially the size method would always operate in a READ_COMMITTED like state, using REPEATABLE_READ doesn't seem feasible since we can't keep all the contents in memory. Essentially the iterator would be ran and for each key that is found it checks the context to see if it is there. If the context entry is marked as removed it doesn't count the key, if the key is there it marks the key as found and counts it, and if it is not found it counts it. Then after iteration it finds all the keys in the context that were not found and also adds them to the count. This way it doesn't need to store additional memory (besides iteration costs) as all the context information is in memory.

My original thought was to also make the EntryIterator transactional in the same way which also means the keySet, entrySet and values methods could do the same things. The main reason stumbling block I had was the fact that the iterator and various collections returned could be used outside of the ongoing transaction which didn't seem to make much sense to me. But maybe these should be changed to be more like backing maps which HashMap, ConcurrentHashMap etc use for their methods, where instead it would pick up the transaction if there is one in the current thread and if there is no transaction just start an implicit one.

This however was a big change from how these collections work currently in that they are in memory copies only. What do you guys think?