<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Thanks for the paper, Paolo - I'll have a read of it over the weekend.<div><br><div><div><div>On 9 Jun 2011, at 21:47, Paolo Romano wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
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]. <br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
<br>
P<br>
<br>
[1] <a class="moz-txt-link-abbreviated" href="http://www.cis.upenn.edu/acg/papers/cal06_atomic_semantics.pdf">www.cis.upenn.edu/acg/papers/cal06_atomic_semantics.pdf</a><br>
<br>
On 6/9/11 9:39 PM, Manik Surtani wrote:
<blockquote cite="mid:E5420ED2-B272-4331-BCBD-817F20295300@jboss.org" type="cite">Regarding the comment on transactional versus
non-transactional threads mentioned on <a moz-do-not-send="true" href="https://issues.jboss.org/browse/ISPN-1137">https://issues.jboss.org/browse/ISPN-1137</a> -
I think the fact that we allow this is a flaw.
<div><br>
</div>
<div>The approach we are taking with JSR 107 is such:</div>
<div><br>
</div>
<div>1) If a cache is non-transactional, transactional threads
accessing the cache throw an exception.</div>
<div>2) If a cache is transactional, threads must have an ongoing
transaction. If not, an exception is thrown, unless:</div>
<div>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.</div>
<div><br>
</div>
<div>See <a moz-do-not-send="true" href="https://groups.google.com/forum/#%21topic/jsr107/WW-ObwfFEbI">https://groups.google.com/forum/#!topic/jsr107/WW-ObwfFEbI</a> -
and feel free to chime on on that list as well. :-)</div>
<div><br>
</div>
<div>This is another relevant and interesting thread: <a moz-do-not-send="true" href="https://groups.google.com/forum/#%21topic/jsr107/iFo20hxQKSw">https://groups.google.com/forum/#!topic/jsr107/iFo20hxQKSw</a></div>
<div><br>
</div>
<div>Cheers</div>
<div>Manik</div>
<div><br>
</div>
<div><br>
<div>
<div>On 9 Jun 2011, at 20:31, Manik Surtani wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word;">Good summary, Mircea.
Breaking it down - and the specific design as well in the
JIRAs - makes it seem almost trivial to implement. ;)
<div><br>
<div>
<div>On 24 May 2011, at 22:36, Mircea Markus wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word;">Hi,
<div><br>
</div>
<div>This is re: <a moz-do-not-send="true" href="http://community.jboss.org/wiki/PossibleLockingImprovements">http://community.jboss.org/wiki/PossibleLockingImprovements</a></div>
<div><br>
</div>
<div>I've created JIRAs for the locking
optimisations as follows:</div>
<div><br>
</div>
<div>#1: <a moz-do-not-send="true" href="https://issues.jboss.org/browse/ISPN-1131">https://issues.jboss.org/browse/ISPN-1131</a></div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
<blockquote type="cite">
<div style="word-wrap: break-word;">
<div>#2: this seems to be just a particular case
of #4 </div>
<div>#3: <a moz-do-not-send="true" href="https://issues.jboss.org/browse/ISPN-1132">https://issues.jboss.org/browse/ISPN-1132</a></div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
<blockquote type="cite">
<div style="word-wrap: break-word;">
<div>#4: <a moz-do-not-send="true" href="https://issues.jboss.org/browse/ISPN-1137">https://issues.jboss.org/browse/ISPN-1137</a></div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Manik</div>
<div>--</div>
</div>
<div>
<div>
<div>Manik Surtani</div>
<div><a moz-do-not-send="true" href="mailto:manik@jboss.org">manik@jboss.org</a></div>
<div><a moz-do-not-send="true" href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div>
<div><br>
</div>
<div>Lead, Infinispan</div>
<div><a moz-do-not-send="true" href="http://www.infinispan.org/">http://www.infinispan.org</a></div>
<div><br>
</div>
</div>
<br class="Apple-interchange-newline">
</div>
<br>
</div>
</div>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote>
</div>
<br>
<div>
<div>
<div>--</div>
<div>Manik Surtani</div>
<div><a moz-do-not-send="true" href="mailto:manik@jboss.org">manik@jboss.org</a></div>
<div><a moz-do-not-send="true" href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div>
<div><br>
</div>
<div>Lead, Infinispan</div>
<div><a moz-do-not-send="true" href="http://www.infinispan.org/">http://www.infinispan.org</a></div>
<div><br>
</div>
</div>
<br class="Apple-interchange-newline">
</div>
<br>
</div>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div>Lead, Infinispan</div><div><a href="http://www.infinispan.org">http://www.infinispan.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline">
</div>
<br></div></div></body></html>