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
>> manik(a)jboss.org
>>
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
>
> --
> Manik Surtani
> manik(a)jboss.org
>
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev