Форум » LetoDB, HbNetio. » Leto DB Server (продолжение) » Ответить
Leto DB Server (продолжение)
alkresin: Только что открыл на Sourceforge новый проект - Leto DB Server - https://sourceforge.net/projects/letodb Это мультиплатформенный ( Windows, Unix/Linux ) сервер баз данных, предоставляющий клиентским программам доступ к dbf/cdx файлам, находящимся на удаленном сервере ( можно и на локальном компьютере запускать - в отладочных целях ). В общем, как ADS :). Проект - на стадии разработки, не все даже базовые функции еще реализованы, до оптимизации дело еще не дошло. Но работает :). Крутится у меня на сервере несколько дней, подключал до 15 клиентов, пока не падает. Мои программы работают с ним нормально. Преимущества по сравнению с обычным файл-сервером: 1) Безопасность - базы могут быть в каталоге, недоступном для клиентских компьютеров - никто их случайно не удалит и не повредит. 2) Поскольку базы открываются серверной программой, а не клиентской, ее целостности ничего не грозит при случайном отключении клиентского компьютера. 3) значительное уменьшение сетевого траффика. 4) Должен быть, по идее, выигрыш в скорости. 5) Возможность контроля за пользователями с помощью утилиты manage ( можно придумать и другие формы контроля ). 6) Можно будет сделать транзакции, stored procedures на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
alkresin: Да есть. Предположим, я решил оформить расчет зарплаты 1-го работника как транзакцию. Вот именно тут я с вами несогласен. По моему глубокому убеждению, транзакция предназначена исключительно для записи данных, все остальное - до и после нее. Я понимаю, что удобно просто выделить кусок кода, ничего в нем не меняя, поставить в начале и в конце begintransaction/endtransaction - и все. Но это, вообще говоря, порочный подход. Впрочем, в самой по себе корректировке из буфера, которую вы предлагаете, ничего плохого нет. Другое дело, что я не рекомендовал бы использовать транзакции так, чтобы она могла понадобиться :).
alkresin: может стоит переписать оставшиеся функции на C ? Стоит. И надо избавиться от класса HApp и, соответственно, PUBLIC oApp. Я тут переписал mt на Harbour модель и у меня теперь при вызове этих функций сервер падает, т.к. второй поток не знает переменной oApp. Т.е. надо или при создании нового потока создавать новую oApp и читать ini файл, или, что явно лучше, хранить все данные oApp на С уровне.
Pasha: Поскольку с сервисом быстро сделать не получится, добавил в качестве примера утилиту letotray для запуска/останова сервера
Pasha: Что-то в сервере не нахожу функции HS_RECORDINFO А она вызывается. Потерялась ?
alkresin: Потерялась ? Без малейшего понятия.
sashaBG: Вот Пример для LetoDBTray на MiniGUI Ext (сб.83) Правда я тут прицепил и NETIO :) LETODB.EXE собран с harbour 1.0.1 RDDLETO.LIB с Харбуром из сборки MiniGUI Ext click here За основу взята INET_CHECKER Григория Филатова PS: На Tray Иконку Щелкать левой кнопкой
alkresin: Добавил source/server/leto_2.c - ядро, основанное на Harbour mt. Пару тестов прогнал - работает. На скорость и прочее не проверял еще. Makefile's еще не выкладывал. Если надо скомпилировать - в нужном makefile замените letocore.c на leto_2.c и hbvm.lib - на hbvmmt.lib
PSP: sashaBG, мне понравилось. :)
Andrey: sashaBG пишет: Вот Пример для LetoDBTray на MiniGUI Ext (сб.83) Классно ! И мне тоже понравилось. Только как перезапускать LetoDb с другого - удаленного компа ?
sashaBG: Вот Так click here только надо указать правильно IP адрес А в етой програмке предусмотрен перезапуск сервера , если он остановится по ошибке Сделайте letodb stop вручную и увидите как иконка становится красной а потом опять зеленой
Pasha: Я занимаюсь переводом PRG --> C для OpenTable и что там еще осталось
Pasha: alkresin пишет: Добавил source/server/leto_2.c - ядро, основанное на Harbour mt. Пару тестов прогнал - работает. На скорость и прочее не проверял еще. Makefile's еще не выкладывал. Если надо скомпилировать - в нужном makefile замените letocore.c на leto_2.c и hbvm.lib - на hbvmmt.lib На первый взгляд, все работает. Но я тоже только у себя тестировал, в работу не ставил. Хотя у меня и с прежней моделью сервер (собранный с xHarbour) не падал, так что я на таком уровне протестировать не смогу. alex_on, а ваша проблема с падением сервера не исчезла ? А как в дальнейшем предполагается использовать потоки ? Может быть, для каждого соединения создавать отдельный поток ? Так было бы логично, и с транзакцией было бы все как положено, и различные пользователи не мешали бы друг другу.
alx_on: Pasha пишет: alex_on, а ваша проблема с падением сервера не исчезла ? Пока только тестирую Нет времени с связи с переездом. Может быть, для каждого соединения создавать отдельный поток ? Слишком накладно (если соединений более 15). У нас доходит до 150 и более, при таком кол-во на переключение потоков будет времени уходить больше, чем на обработку команд
alkresin: А как в дальнейшем предполагается использовать потоки ? Может быть, для каждого соединения создавать отдельный поток ? Думать надо. Вариант с потоком на каждое соединение привлекателен своей простотой, но ... см.выше - Александр все правильно сказал. Тот же ADS использует фиксированное количество потоков, т.е. он как-то распределяет работу между ними. Скорее всего, на каждый запрос выделяется первый свободный поток, а если таковых нет, то запрос помещается в очередь. Тоже вариант, кстати. Но я бы предпочел, чтобы все транзакции выполнялись только одним потоком - при этом реализуется то их важное свойство, название которого я забыл :). Учитывая, что время исполнения транзакции сравнительно невелико - это не фильтрация, не индексация и т.п. - то ступора не должно быть. Для начала надо проверить и отработать механизм с hb_rddDetachArea() и hb_rddRequestArea().
Pasha: Транзакция (commit) и так выполняется на сервере одним запросом, так что это укладывается в схему фиксированного числа потоков. Правда, во время транзакции могут быть еще запросы на чтение данных. Для запросов на чтение требование выполнения в одном потоке критично ? Ведь их посылает один клиент, и следующий запрос не пройдет, пока не получен ответ по предыдущему. А количество потоков можно сделать настраиваемым - как в ADS к примеру. По умолчанию 8 с возможностью перенастройки.
alkresin: Транзакция (commit) и так выполняется на сервере одним запросом, так что это укладывается в схему фиксированного числа потоков. Не совсем понял, что вы имеете ввиду, но я говорил о том, чтобы все транзакции выполнялись в одном потоке, строго одна за другой, а не так, что одна транзакция в потоке А, а другая в это время параллельно в потоке Б.
Pasha: alkresin пишет: Не совсем понял, что вы имеете ввиду, но я говорил о том, чтобы все транзакции выполнялись в одном потоке, строго одна за другой, а не так, что одна транзакция в потоке А, а другая в это время параллельно в потоке Б. Теперь понятно, я говорил о другом
alx_on: alkresin пишет: одна транзакция в потоке А, а другая в это время параллельно в потоке Б Имелось в виду commit или весь период от начала до конца? Если только commit и совсем ничего не придумаем, то можно тупо блокировать потоки с транзакциями и обрабатывать commit по очереди
alkresin: Имелось в виду commit или весь период от начала до конца? Не понял. Какой период ? Какой фрагмент leto_Transaction() вы называете commit ? Зачем раздавать транзакции по потокам и блокировать их исполнение, а не просто выполнять их по очереди в одном потоке ?
alx_on: alkresin пишет: Какой период ? Какой фрагмент leto_Transaction() вы называете commit ? Имелось в виду с точки зрения клиентской части в том числе, т.е. LETO_COMMITTRANSACTION() Зачем раздавать транзакции по потокам и блокировать их исполнение, а не просто выполнять их по очереди в одном потоке ? Т.е. только один поток будет выполнять транзакции? А если все идет через транзации? Тогда в некоторых случаях мы не сможем разделить по потокам задачи.
полная версия страницы