Отправлено: 31.01.08 11:36. Заголовок: Leto DB Server(продолжение)

Только что открыл на 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 на Харборе, ... и вообще все в наших руках :).

Кто хочет участвовать в разработке, тестировании - пишите.

 Отправлено: 06.01.11 18:21. Заголовок: PSP пишет: А как об..

PSP пишет:

цитата:

А как объяснить, что вьювер тоже не видит изменений?

То, что вьювер вообще получает доступ к таблице, открытой letodb, говорит нам, что letodb работает в режиме Share_Tables. Это неэффективный режим, в режиме монопольного доступа letodb работает лучше.
А обьяснение простое. Сервер letodb - это тот же dbfcdx. А как известно, путь от простого dbCommit к физической записи данных на диск труден и долог. Сначала dbfcdx сбрасывает эти данные в буфер операционки. А уж когда она соизволит их записать на диск - можно только догадываться. И лишь после этого их сможет увидеть вьювер. Который, кстати, тоже может не сразу обновить данные, у него может свой буфер имеется.

 Отправлено: 06.01.11 20:53. Заголовок: Pasha пишет: letodb..

Pasha пишет:

цитата:

letodb работает в режиме Share_Tables

Нет. Я специально в ini-файле даже Share_Tables = 0 поставил.
У меня тоже такая мысль была. По идее сервер не должен давать доступ.

 Отправлено: 06.01.11 20:55. Заголовок: Pasha пишет: Которы..

Pasha пишет:

цитата:

Который, кстати, тоже может не сразу обновить данные, у него может свой буфер имеется

Я его многократно открываю-закрываю. Результат одинаковый.

 Отправлено: 07.01.11 15:04. Заголовок: Сейчас попробовал в ..

Сейчас попробовал в файл-серверном варианте с DBFCDX. Две станции пишут по-очереди в одно поле одной записи. При этом не используется ни DBCommit(), ни сдвиг указателя записи. Только Lock и UnLock. Причем, содержимое поля читается и перед записью, и после. Так вот, данные читаются всегда актуальные, на обеих станциях. Так, собственно, и Клиппер работает.

 Отправлено: 07.01.11 19:15. Заголовок: Pasha пишет: Тоже с..

Pasha пишет:

цитата:

Тоже самое касается и sql. Это стандартый вопрос: почему после транзакции другие клиенты ее не видят. И на это есть стандартный ответ: представьте, что после каждой транзакции sql-сервер вдруг начнет плеваться данными на всех подключенных в этот момент клиентов... это же нехорошо ? Вот поэтому клиенты должны сами, того, как тот Магомед, идти к горе.

Паша, извините за позднюю реакцию, диагональное чтение...
На это могу сказать одно: если после завершения транзакции SQL-сервер не вернет клиенту актуальные данные, разве это нормально? У меня именно такая ситуация. Транзакция закончена, клиент запрашивает данные и получает... устаревшие. Разве клиент должен заботиться об актуальности данных на сервере?

 Отправлено: 07.01.11 19:49. Заголовок: Нет конечно. После з..

Нет конечно. После завершения транзакции все запрашиваемые данные должны быть актуальны. Разве в letodb не так ?
Я говорил о том, что уже полученные клиентом данные могут быть неактуальны, и после транзакции с другого клиента надо повторить запрос

 Отправлено: 07.01.11 20:09. Заголовок: Pasha пишет: Разве ..

Pasha пишет:

цитата:

Разве в letodb не так ?

У меня получается, что "не так". Даже после завершения транзакции одной станцией, другая получает устаревшие данные. Проверял на двух серверах: под Ubuntu и под XP. Причем файл-серверный вариант (см.выше) нормально работает.

 Отправлено: 08.01.11 11:20. Заголовок: PSP пишет: У меня п..

PSP пишет:

цитата:

У меня получается, что "не так".

Тогда разбираемся более предметно.

t1.prg:

Field Code, Name

Function main
Local cPath := '//127.0.0.1:2812/', nKey := 0

REQUEST LETO
RDDSETDEFAULT( "LETO" )

cls

dbCreate(cPath + 'test', {{'Code','N',2,0},{'Name','C',20,0}})
use (cPath + 'test') shared new
dbAppend()
dbCommit()

while nKey # 27
rlock()
leto_BeginTransaction()
Field->Code ++
dbCommit()
leto_CommitTransaction()
dbUnlock()
? 'Client 1', Recno(), Field->Code
wait
nKey := LastKey()
enddo

return nil

t2.prg:

Field Code, Name

Function main
Local cPath := '//127.0.0.1:2812/', nKey := 0

REQUEST LETO
RDDSETDEFAULT( "LETO" )

cls

use (cPath + 'test') shared new

while nKey # 27
goto 1
? 'Client 2', Recno(), Field->Code
wait
nKey := LastKey()
enddo

return nil

Запускам t1, выполняем первую транзакцию, выводим значение поля после транзакции
Запускаем t2 - видим то же значение
Переключаемся на t1, выполняем следующую транзакцию, переключаемся на t2 - видим то же самое значение. И так далее

Получается что "так"
Где собака порылась ?

 Отправлено: 08.01.11 11:41. Заголовок: С "goto 1" в..

С "goto 1" все "так". А без него "нет так".
А теперь тот же пример, но без Leto, через DBFCDX.
Исключаем "goto 1" - все работает "так". Даже без dbCommit(). В чем прикол?
Почему драйвер DBFCDX позволят другой станции без сдвига указателя прочитать актуальные данные, а выполнение leto_CommitTransaction() не позволяет? Извините за нудность, просто налетел на эту фичу на рабочей базе.
Кстати, в версиях Leto начала 2010 года (точно не скажу, не сохранилось), все работало "так" и без "goto". :)

 Отправлено: 08.01.11 12:06. Заголовок: PSP пишет: С "g..

PSP пишет:

цитата:

С "goto 1" все "так". А без него "нет так".

Без goto данные на 2-м клиенте не обновляются.
Первый раз клиент 2 выдал запрос серверу на 1-ю запись и получил ее. Затем в цикле он, не запрашивая обновленные данные, выводит то значение, которое он получил первый раз, то есть необновленное. Как вы себе представляете, клиентская программа должна сама по себе без пинка запрашивать обновленные данные с сервера ? Чтобы обновить запись, надо либо сместить указатель текущей записи и вернуться на нужную, либо выдать dbgoto(recno()) или dbskip(0).
Правда, в лето есть еще механизм кеширования skip, но здесь он не работает, не будем усложнять.

 Отправлено: 08.01.11 12:11. Заголовок: Вот пример без лето ..

Вот пример без лето и без goto

t1.prg

Field Code, Name

Function main
Local cPath := '', nKey := 0

cls

dbCreate(cPath + 'test', {{'Code','N',2,0},{'Name','C',20,0}})
use (cPath + 'test') shared new
dbAppend()
dbCommit()

while nKey # 27
rlock()
Field->Code ++
dbCommit()
dbUnlock()
? 'Client 1', Recno(), Field->Code
wait
nKey := LastKey()
enddo

return nil

t2.prg

Field Code, Name

Function main
Local cPath := '', nKey := 0

cls

use (cPath + 'test') shared new

while nKey # 27
// goto 1
? 'Client 2', Recno(), Field->Code
wait
nKey := LastKey()
enddo

return nil

И что мы видим: да никакой мистики с фантастикой, 2-й клиент видит необновленные данные. Все работает, как и должно работать

 Отправлено: 08.01.11 12:16. Заголовок: Pasha пишет: Как вы..

Pasha пишет:

цитата:

Как вы себе представляете, клиентская программа должна сама по себе без пинка запрашивать обновленные данные с сервера ? Чтобы обновить запись, надо либо сместить указатель текущей записи и вернуться на нужную, либо выдать dbgoto(recno()) или dbskip(0).

Я всегда думал, что выдача актуальных данных - забота сервера. Клиент вправе считать полученные данные актуальными в любой момент времени и не знает, когда ему нужно сдвинуть указатель, а когда не нужно. Тем более, если указатель уже находится на нужной записи.
Ладно, вопрос можно считать закрытым. Паше спасибо за терпение. :)

 Отправлено: 08.01.11 12:29. Заголовок: PSP пишет: Я всегда..

PSP пишет:

цитата:

Я всегда думал, что выдача актуальных данных - забота сервера.

Единственная забота сервера - обслужить клиента, т.е обработать его запрос. Сервер сам по себе клиенту ничего не посылает.
Если бы это было так, то это был бы не клиент-сервер, а сервер-сервер. На стороне клиента пришлось бы делать какой-то диспетчер запросов, принимать команды с сервера...

 Отправлено: 08.01.11 14:27. Заголовок: Да уж... Развил я ту..

Да уж... Развил я тут тему... :) Паша, еще раз спасибо за терпение.

 Отправлено: 13.01.11 21:42. Заголовок: как letodb сейчас ра..

как letodb сейчас работает на многоядерных системах?

 Отправлено: 14.01.11 17:03. Заголовок: Dimka пишет: как le..

Dimka пишет:

цитата:

как letodb сейчас работает на многоядерных системах?

В letodb используется 2 потока. Значит, будет работать как обычное многопоточное приложение. Я специально не исследовал этот вопрос, но думается, что каждое ядро будет выполнять отдельный поток

 Отправлено: 23.01.11 15:22. Заголовок: Добавил новую функци..

Добавил новую функцию: Leto_Commit()
Она заменяет вызовы:

dbCommit()
dbUnlock()

Обычно клиент посылает серверу 3 пакета : для обновления записи, для commit и для unlock
Новая функция посылает только один пакет для всех этих операций. Таким образом, при обновлении данных количество пакетов можно уменьшить втрое

 Отправлено: 23.01.11 22:10. Заголовок: Pasha пишет: Таким ..

Pasha пишет:

цитата:

Таким образом, при обновлении данных количество пакетов можно уменьшить втрое

Классное решение ! Спасибо за рацпредложение и исполнение его !

 Отправлено: 25.01.11 13:35. Заголовок: пытаюсь начать польз..

пытаюсь начать пользоваться letodb. на одном большом рассчете программка начинает течь и занимает 1гб оперативы и более. успокойте меня, скажите что это изза того, что используются индексы NTX. и команда USE делает последний из перечисленных индексов активным.

 Отправлено: 25.01.11 16:17. Заголовок: Dimka пишет: успоко..

Dimka пишет:

цитата:

успокойте меня, скажите что это изза того, что используются индексы NTX. и команда USE делает последний из перечисленных индексов активным.

Фантазировать мы не будем. Лучше попробуйте выяснить, какое действие является причиной протечки. Очень уж воды много выливается. У меня вот приличная по размеру программа занимает всего 12М, а тут целый гектар, впечатляет.