передача временной таблицы с клиента на сервер

[S.Kuskov]

Ясно...

Да, жалко что нет инструмента копирования целиком табличного буфера без разделения на части или перепаковки.

UPD:
А такого инструмента наверное и не может быть. Ведь наверняка в общем случае буфер временной таблицы хранится фрагментированно совместно с другими данными в куче. И что бы передать его одним куском, этот один кусок сначала нужно собрать, на деле перепаковав табличный буфер в статическую непрерывную структуру вроде контейнера.

[fed]

Цитата:

Сообщение от S.Kuskov

Ясно...

Да, жалко что нет инструмента копирования целиком табличного буфера без разделения на части или перепаковки.

UPD:
А такого инструмента наверное и не может быть. Ведь наверняка в общем случае буфер временной таблицы хранится фрагментированно совместно с другими данными в куче. И что бы передать его одним куском, этот один кусок сначала нужно собрать, на деле перепаковав табличный буфер в статическую непрерывную структуру вроде контейнера.

Тут речь идет скорее не об одном буфере, а о том чтобы все записи таблицы в контейнер запаковать и потом чохом передать. Я для этого делал два метода в global - packTable и unpackTable... Да и дело тут не в памяти, а просто в экономии RPC при передаче параметров...

[S.Kuskov]

Цитата:

Сообщение от fed

чохом передать

Это я уже понял. Просто хотел уточнить. Для того чтобы чохом передать нужно же и "чохом" хранить? Или не обязательно? Т.е. очень сомнительно, что за один "чох" можно передать, например, динамическую структуру типа Map? Мне почему-то кажется что должно выполнятся условие размещения данных в одном передаваемом куске памяти. Я ошибаюсь?

[AndyD]

Цитата:

Сообщение от S.Kuskov

Это я уже понял. Просто хотел уточнить. Для того чтобы чохом передать нужно же и "чохом" хранить? Или не обязательно? Т.е. очень сомнительно, что за один "чох" можно передать, например, динамическую структуру типа Map? Мне почему-то кажется что должно выполнятся условие размещения данных в одном передаваемом куске памяти. Я ошибаюсь?

Так все в кучке и хранится.
Либо в памяти (если не очень много успели записать), либо уже на диске, но все вместе

Только RPC не надо идеализировать
Большие контейнеры тоже будут передавать не целиком за раз, а разбиваться на куски. Соответственно, дополнительных вызовов будет достаточно много.
Но, в любом случае, таких обменов будет меньше, чем при условии передачи по каждой отдельной записи

[S.Kuskov]

Цитата:

Сообщение от AndyD

Так все в кучке и хранится.
Либо в памяти (если не очень много успели записать), либо уже на диске, но все вместе

Т.е. вы хотите сказать, что под буфер временной таблицы сразу выделяется какой-то фиксированный максимальный размер памяти. Я считал что память под структуры таких размеров должна выделяться по мере необходимости, т.е. динамически. Возможно я немного переоцениваю объём памяти занимаемый временными таблицами.

В любом случае, если бы была реализация копировани буфера временной таблицы на уровне ядра системы, то это бы помогло бы избежать ненужных накладных расходов на переупаковку данных и в тоже время не повысила бы Chattiness

[S.Kuskov]

Logger, я всё это прекрасно понимаю. Я лишь хотел убедится, что "НЕ элементарные" типы передать за один/два RPC вызова нельзя. Но после сообщения AndyD

Цитата:

Сообщение от AndyD

Так все в кучке и хранится.
Либо в памяти (если не очень много успели записать), либо уже на диске, но все вместе

хотелось бы убедится ещё и в том как именно хранится буфер временной таблицы в оперативной памяти. Как строка в одном месте или фрагментировано в разных связанных областях? Для общего развития так сказать. Просто когда представляешь себе как это там на самом деле всё происходит многие вещи становятся понятнее. Например почему таки нельзя просто взять и скопирования буфер временной таблицы так же как строку или контейнер?

[gl00mie]

Цитата:

Сообщение от S.Kuskov

Почему таки нельзя просто взять и скопирования буфер временной таблицы так же как строку или контейнер?

Если говорить о передаче по сети объекта "по значению", то в любом случае будут передаваться какие-то данные, представляющие объект. Соотв., объект нужно уметь сериализовать (представить в виде потока данных - бинарных или того же XML) и десериализовать (из потока данных воссоздать представление объекта в памяти). В этом плане те же объекты-коллекции имеют готовые механизмы сериализации/десериализации - экземплярный метод pack() и статический create(), аналогично обстоит дело с классами, реализующими SysPackable. Их можно запаковать на одной стороне в контейнер, "чохом" передать его и распаковать (воссоздать) на другой стороне. Временные таблицы тут отличаются лишь тем, что у них нет собственного механизма сериализации/десериализации, поэтому приходится приделывать им костылики.

Цитата:

Сообщение от S.Kuskov

Я лишь хотел убедится, что "НЕ элементарные" типы передать за один/два RPC вызова нельзя.

При передаче объекта "по значению" все зависит от того, поместится ли его сериализованное представление в один/два RPC-пакета или нет.