Re: [infinispan-dev] locking optimisations reloaded

Regarding the comment on transactional versus non-transactional threads mentioned on https://issues.jboss.org/browse/ISPN-1137 - I think the fact that we allow this is a flaw. The approach we are taking with JSR 107 is such: 1) If a cache is non-transactional, transactional threads accessing the cache throw an exception. 2) If a cache is transactional, threads must have an ongoing transaction. If not, an exception is thrown, unless: 3) Auto-commit is configured to be true. In this case, if a non-transactional thread accesses the cache, a tx is started, work done, and the tx auto-committed. See https://groups.google.com/forum/#!topic/jsr107/WW-ObwfFEbI <https://groups.google.com/forum/#%21topic/jsr107/WW-ObwfFEbI> - and feel free to chime on on that list as well. :-) This is another relevant and interesting thread: https://groups.google.com/forum/#!topic/jsr107/iFo20hxQKSw <https://groups.google.com/forum/#%21topic/jsr107/iFo20hxQKSw> Cheers Manik On 9 Jun 2011, at 20:31, Manik Surtani wrote: > Good summary, Mircea. Breaking it down - and the specific design as > well in the JIRAs - makes it seem almost trivial to implement. ;) > > On 24 May 2011, at 22:36, Mircea Markus wrote: > >> Hi, >> >> This is re: http://community.jboss.org/wiki/PossibleLockingImprovements >> >> I've created JIRAs for the locking optimisations as follows: >> >> #1: https://issues.jboss.org/browse/ISPN-1131 > > Keep in mind the LockingInterceptor delegates a lot of the > copyOnWrite (of CacheEntries) and the corresponding locking to the > EntryFactoryImpl. This too would probably need to be subclassed. > >> #2: this seems to be just a particular case of #4 >> #3: https://issues.jboss.org/browse/ISPN-1132 > > Looks good, however I'm concerned about the key comparator and how > this would deterministically order keys. Basing order on hashcode > can lead to collisions (and if using the default Object.hashcode > breaks down completely). And we can't *require* that users provide > one; we'd need to provide a sensible - if suboptimal - default. > >> #4: https://issues.jboss.org/browse/ISPN-1137 > > Paolo's concerns are very valid. Vector clocks to determine order of > application on non-primary owner node is one mechanism that would > work; another may be that each node only ever communicates with the > primary owner. And the primary owner then has the responsibility of > propagating prepares and commits to other peers. This will mean > eventual consistency though, since concurrent readers would always > have to read from the primary owner since reading from other owners > of an entry may result in stale data. > > Another potential problem here is failover. You should discuss how > you intend to deal with failure in the primary owner, with different > transactions at various stages of completion. > > Cheers > Manik > -- > Manik Surtani > manik(a)jboss.org <mailto:manik@jboss.org> > twitter.com/maniksurtani <http://twitter.com/maniksurtani> > > Lead, Infinispan > http://www.infinispan.org <http://www.infinispan.org/> > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org <mailto:manik@jboss.org> twitter.com/maniksurtani <http://twitter.com/maniksurtani> Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev