Denis, I think the current state of fix for SQL queries is consistent with the highlighted topics, except
- server node mustn’t create a copy if a result set will be transferred 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 state and provide suggestions. 2016-07-07 13:32 GMT+03:00 Denis Magda <dma...@gridgain.com>: > I would say that, yes, we should make copyOnRead flag consistent across > all cache ‘get’ like operations. However we need to make sure that the copy > is not created in the following cases > > - server node mustn’t create a copy if a result set will be transferred to > a remote node; > - client node or other remote node mustn’t create a copy after it 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’t make sense to make a > copy in any case since Java heap already has a copy of data from off heap. > 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? > > — > Denis > > > On Jul 7, 2016, at 12:18 PM, Alexei Scherbakov < > alexey.scherbak...@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
