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 > [email protected] > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
