Thanks for the paper, Paolo - I'll have a read of it over the weekend. On 9 Jun 2011, at 21:47, Paolo Romano wrote:
> There has been a lot of discussion on this topic also in the Transactional > Memory area, triggered to the best of my knowledge by this paper [1]. > > Mixing transactional and non-transactional access to shared state opens a > number of subtle scenarios and there are a pile of follow-up papers on how to > try to make tx and non-tx access coexist (what is called strong-atomicity in > TM terminology), and it typically implies adding a good deal of complexity > and overheads. > > My opinion is fully aligned with Galder's & Manik's view: enforcing a neat > and clear separation at the API level in order to prevent mixing tx and > non-tx access is the way to go. This ensures that non-tx accesses can be > supported by fast and clean mechanisms, while also simplifying management of > transactions. > > Cheers, > > P > > [1] www.cis.upenn.edu/acg/papers/cal06_atomic_semantics.pdf > > On 6/9/11 9:39 PM, Manik Surtani wrote: >> >> 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 - 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 >> >> 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 >>> ma...@jboss.org >>> twitter.com/maniksurtani >>> >>> Lead, Infinispan >>> http://www.infinispan.org >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> ma...@jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
