On 18 Jun 2013, at 14:16, Dan Berindei wrote:
> On Mon, Jun 17, 2013 at 7:00 PM, Mircea Markus wrote:
>
> On 17 Jun 2013, at 16:11, Dan Berindei wrote:
>
> > > I think that, given that the local node is not owner, the lock
> > > acquisition is redundant even for pessimistic caches.
> > > Mi
On Tue, Jun 18, 2013 at 4:41 PM, William Burns wrote:
>
>
>
> On Tue, Jun 18, 2013 at 9:23 AM, Dan Berindei wrote:
>
>>
>>
>>
>> On Mon, Jun 17, 2013 at 6:35 PM, William Burns wrote:
>>
>>>
>>>
>>>
>>> On Mon, Jun 17, 2013 at 11:11 AM, Dan Berindei
>>> wrote:
>>>
On Mon, Jun
On Tue, Jun 18, 2013 at 9:23 AM, Dan Berindei wrote:
>
>
>
> On Mon, Jun 17, 2013 at 6:35 PM, William Burns wrote:
>
>>
>>
>>
>> On Mon, Jun 17, 2013 at 11:11 AM, Dan Berindei wrote:
>>
>>>
>>>
>>>
>>> On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo wrote:
>>>
On 06/17/2013 12:56 PM, M
On Mon, Jun 17, 2013 at 6:35 PM, William Burns wrote:
>
>
>
> On Mon, Jun 17, 2013 at 11:11 AM, Dan Berindei wrote:
>
>>
>>
>>
>> On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo wrote:
>>
>>>
>>>
>>> On 06/17/2013 12:56 PM, Mircea Markus wrote:
>>> >
>>> > On 17 Jun 2013, at 11:52, Pedro Ruivo wrot
On Mon, Jun 17, 2013 at 7:00 PM, Mircea Markus wrote:
>
> On 17 Jun 2013, at 16:11, Dan Berindei wrote:
>
> > > I think that, given that the local node is not owner, the lock
> acquisition is redundant even for pessimistic caches.
> > > Mind creating a test to check if dropping that lock acquisi
On 17 Jun 2013, at 16:11, Dan Berindei wrote:
> > I think that, given that the local node is not owner, the lock acquisition
> > is redundant even for pessimistic caches.
> > Mind creating a test to check if dropping that lock acquisition doesn't
> > break things?
>
> I created a JIRA with lo
On Mon, Jun 17, 2013 at 11:11 AM, Dan Berindei wrote:
>
>
>
> On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo wrote:
>
>>
>>
>> On 06/17/2013 12:56 PM, Mircea Markus wrote:
>> >
>> > On 17 Jun 2013, at 11:52, Pedro Ruivo wrote:
>> >
>> >> I've been looking at TxDistributionInterceptor and I have a
On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo wrote:
>
>
> On 06/17/2013 12:56 PM, Mircea Markus wrote:
> >
> > On 17 Jun 2013, at 11:52, Pedro Ruivo wrote:
> >
> >> I've been looking at TxDistributionInterceptor and I have a couple of
> >> questions (assuming REPEATABLE_READ isolation level):
>
On 17 Jun 2013, at 13:58, Pedro Ruivo wrote:
>>>
>>> After this analysis, it is possible to break the isolation between
>>> transaction if I do a get on the key that does not exist:
>>>
>>> tm.begin()
>>> cache.get(k) //returns null
>>> //in the meanwhile a transaction writes on k and commits
On 06/17/2013 12:56 PM, Mircea Markus wrote:
>
> On 17 Jun 2013, at 11:52, Pedro Ruivo wrote:
>
>> I've been looking at TxDistributionInterceptor and I have a couple of
>> questions (assuming REPEATABLE_READ isolation level):
>>
>> #1. why are we doing a remote get each time we write on a key? (
On 17 Jun 2013, at 11:52, Pedro Ruivo wrote:
> I've been looking at TxDistributionInterceptor and I have a couple of
> questions (assuming REPEATABLE_READ isolation level):
>
> #1. why are we doing a remote get each time we write on a key? (huge
> perform impact if the key was previously read
Hi guys,
I've been looking at TxDistributionInterceptor and I have a couple of
questions (assuming REPEATABLE_READ isolation level):
#1. why are we doing a remote get each time we write on a key? (huge
perform impact if the key was previously read)
#2. why are we doing a dataContainer.get() if
12 matches
Mail list logo
