As we name the transactions optimistic, wouldn't' it make more sense to have
WSK functionality enabled by default? (even though that would imply using
repeatable_read).
I mean as a user I kind of expect the tx to fail for optimistic transactions
when there's a write skew...
On 27 Sep 2012, at 1
WSK only works for repeatable read. By default we use read committed.
On 27 Sep 2012, at 16:07, Mircea Markus wrote:
> Hi,
>
> By default our optimistic transactions don't have writeSkewCheck enabled so
> their behaviour is counterintuitive for the user. That's because they don't
> fault th
Hi,
By default our optimistic transactions don't have writeSkewCheck enabled so
their behaviour is counterintuitive for the user. That's because they don't
fault the commit in the case of a concurrent change.
Anyone can remember why these defaults are being used?
I'd rather have optimistic tr
https://issues.jboss.org/browse/ISPN-2353
On 12-09-27 1:47 PM, Matej Lazar wrote:
> NPE ocures while running CapeDwarf cluster tests, see stack below.
>
> Null comes from MapReduceTask.invokeEverywhere
>
> 13:36:51,053 INFO [org.jboss.as.clustering.infinispan]
> (http-/192.168.30.248:8080-1) JBAS
NPE ocures while running CapeDwarf cluster tests, see stack below.
Null comes from MapReduceTask.invokeEverywhere
13:36:51,053 INFO [org.jboss.as.clustering.infinispan]
(http-/192.168.30.248:8080-1) JBAS010281: Started search_capedwarf-test cache
from capedwarf container
13:36:51,058 DEBUG [
On Sep 25, 2012, at 6:07 PM, Sanne Grinovero wrote:
> On 25 September 2012 16:41, Galder Zamarreño wrote:
>>
>> On Sep 25, 2012, at 4:51 PM, Manik Surtani wrote:
>>
>>>
>>> On 25 Sep 2012, at 13:48, Galder Zamarreño wrote:
>>>
On Sep 24, 2012, at 12:27 PM, Manik Surtani wrote:
