[infinispan-dev] locking optimisations reloaded

[Paolo Romano]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110609/6f3ef3db/attachment.html