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