Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMegbc+K_g7q+DDsstWxB=DFr94nXetNXVQZBf9Ccsrrb+zN_Q@mail.gmail.com>
References: <CAMegbcJ1FLhRj=6P+C22vKuSJQuVmsTpk7qWjnNN4HTSKWv6KA@mail.gmail.com>
 <8F65402F-FB05-4944-8C23-FCDEF0E58F44@gridgain.com> <CAMegbc+K_g7q+DDsstWxB=DFr94nXetNXVQZBf9Ccsrrb+zN_Q@mail.gmail.com>
From: Alexei Scherbakov <alexey.scherbakoff@gmail.com>
Date: Thu, 7 Jul 2016 18:51:55 +0300
Message-ID: <CAMegbcJyW4beWwc2C4o64O0Nmnu_pOOsWA1EAad_Nmtaj+x-iA@mail.gmail.com>
Subject: Re: IGNITE-2795
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c048d24587f0405370daa7f
archived-at: Thu, 07 Jul 2016 15:52:08 -0000

--94eb2c048d24587f0405370daa7f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've updated the fix.

Currently all the copying is performed inside query iterators only if
needed.

2016-07-07 14:38 GMT+03:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>=
:

> Denis,
>
> I think the current state of fix for SQL queries is consistent with the
> highlighted topics, except
>
> - server node mustn=E2=80=99t create a copy if a result set will be trans=
ferred to
> a remote node;
>
> I afraid it would be difficult to implement without interfering with
> current implementation too much.
> Will look at this more thoughtfully.
>
> Anyway, it would be useful for me if someone will review the current stat=
e
> and provide suggestions.
>
>
> 2016-07-07 13:32 GMT+03:00 Denis Magda <dmagda@gridgain.com>:
>
>> I would say that, yes, we should make copyOnRead flag consistent across
>> all cache =E2=80=98get=E2=80=99 like operations. However we need to make=
 sure that the copy
>> is not created in the following cases
>>
>> - server node mustn=E2=80=99t create a copy if a result set will be tran=
sferred
>> to a remote node;
>> - client node or other remote node mustn=E2=80=99t create a copy after i=
t
>> receives the result set from the other node.
>>
>> All this means that the copy has to be created if:
>> - node (server) executes local queries or iterates over local data set;
>> - client does the same executing queries or iterating over its local
>> cache.
>> - in my understanding, in OFF_HEAP mode in doesn=E2=80=99t make sense to=
 make a
>> copy in any case since Java heap already has a copy of data from off hea=
p.
>> However this part must be clarified by someone else from the community.
>>
>> Would you mind covering this scenarios in the tests and implementation?
>>
>> Igniters, other thoughts on this?
>>
>> =E2=80=94
>> Denis
>>
>> > On Jul 7, 2016, at 12:18 PM, Alexei Scherbakov <
>> alexey.scherbakoff@gmail.com> wrote:
>> >
>> > Igniters,
>> >
>> > I implemented a fix for copy-on-read semantics for cache objects
>> returned
>> > from SQL queries and need a review.
>> >
>> > See the issue <https://issues.apache.org/jira/browse/IGNITE-2795>for
>> > details on PR.
>> >
>> > While developing a fix I also noticed the same bug in local cache
>> > iterators.
>> >
>> > To make a behavior of copyOnRead consistent across all cache
>> operations, I
>> > think we should fix it as well.
>> >
>> > Thoughts?
>> >
>> > --
>> >
>> > Best regards,
>> > Alexei Scherbakov
>>
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>


--=20

Best regards,
Alexei Scherbakov

--94eb2c048d24587f0405370daa7f--