On Oct 10, 2014, at 17:30, William Burns <mudokon...@gmail.com> wrote:
>>>>> 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. sounds good to me. > > 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. or if they are outside of a transaction to deny progress > 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? I think that keeping track of the context entries is a better way of iterating so +1. As you mentioned, we should also make it clear that RC semantic applies. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev