SASGIS - SAS.Планета |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0000745 | SAS.Планета | [All Projects] Хотелка | public | 18-05-2011 16:42 | 22-07-2011 17:02 |
|
Reporter | gpsMax | |
Assigned To | vdemidov | |
Priority | none | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | won't fix | |
Platform | | OS | | OS Version | |
Product Version | 110418 | |
Target Version | | Fixed in Version | | |
|
Summary | 0000745: Многопользовательский доступ к файлу меток (сложное решение, одновременно сидит несколько пользователей) |
Description | В продолжение хотелки 744. А вдруг возможно сделать по-настоящему многопользовательский доступ с минимумом телодвижений для разработчиков? Даже если и нет, будет хотелка на будущее.
Конечно, SAS не база данных. И даже пользоваться средствами БД не будет ближайшие N лет, поскольку переход с файлового хранилища на базу - процесс нетривиальный и большинству не нужный.
В принципе, можно сделать так: рядом с базой меток лежит файл-флажок (другой, не тот, что в 744 про блокировку). Пользователь, создавший изменение в метках, автоматически обновляет флажок. Программы всех пользователей во время работы должны постоянно мониторить время создания флажка, и когда оно изменяется, то перезагрузить с общего хранилища себе базу меток и сделать у себя же отметку, что флажок с временем создания таким-то отработан (удалять его нельзя - остальные пользователи тогда не увидят изменений).
Схема несложная, но на практике чреватая тормозами у всех участников по каждому чиху кого-либо из них. Это надо смотреть и думать, как оптимизировать сей процесс.
Возможно, кто-то придумает и другую схему, не такую прямолинейную. |
Steps To Reproduce | |
Additional Information | |
Tags | доступ |
Relationships | related to | 0000744 | closed | Parasite | Многопользовательский доступ к файлу меток (простое минимальное решение, одновременно сидит один юзер) | related to | 0000173 | closed | vasketsov | Добавить в SASPlanet.ini указание пути к файлам меток (аналогично существующему пути для кэша) |
|
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
18-05-2011 16:42 | gpsMax | New Issue | |
18-05-2011 16:42 | gpsMax | Relationship added | related to 0000744 |
18-05-2011 16:44 | gpsMax | Tag Attached: доступ | |
18-05-2011 16:45 | gpsMax | Relationship added | related to 0000173 |
18-05-2011 16:46 | gpsMax | Status | new => acknowledged |
18-05-2011 17:55 | Parasite | Note Added: 0002581 | |
19-05-2011 11:41 | gpsMax | Note Added: 0002594 | |
20-05-2011 05:50 | Parasite | Note Added: 0002616 | |
20-05-2011 05:52 | Parasite | Note Edited: 0002616 | bug_revision_view_page.php?bugnote_id=2616#r1257 |
21-07-2011 05:29 | vdemidov | Note Added: 0003227 | |
21-07-2011 05:29 | vdemidov | Status | acknowledged => resolved |
21-07-2011 05:29 | vdemidov | Resolution | open => won't fix |
21-07-2011 05:29 | vdemidov | Assigned To | => vdemidov |
22-07-2011 06:05 | Tolik | Note Added: 0003250 | |
22-07-2011 06:05 | Tolik | Status | resolved => closed |
22-07-2011 17:02 | gpsMax | Priority | normal => none |
Notes |
|
|
>можно сделать так: рядом с базой меток лежит файл-флажок (другой, не тот, что в 744 про блокировку). Пользователь, создавший изменение в метках, автоматически обновляет флажок. Программы всех пользователей во время работы должны постоянно мониторить время создания флажка, и когда оно изменяется, то перезагрузить с общего хранилища себе базу меток и сделать у себя же отметку, что флажок с временем создания таким-то отработан (удалять его нельзя - остальные пользователи тогда не увидят изменений).
Попытка реализации тривиального sync - detected.
На самом же деле можно тупо разогнать тот же SQLite (в составе САСа) и общаться с базой меток только через него (через САС-приложение, первым взявшее монопольный доступ к данному хранилищу). Учитывая то, что у среднестатистического хомяка меток немного, а разнесенных САСов - еще меньше, то метод вполне сработает.
PS: именно это реализовано в FireFox например. Первый же запущенный процесс берет монопольное использование например букмарков, settings или там browsing_history - через Sqlite, а все последующие детектируют наличие первого и общаются только через него. В итоге - общие глобальные метки в виде конкретных единичных файлов, и никакого Sharing Violation. Перенес эту кучку баз на другой компьютер - считай, склонировал свой Файрфокс. Именно это сейчас преподносят как "FF Mobile Sync". :) |
|
|
(0002594)
|
gpsMax
|
19-05-2011 11:41
|
|
> можно тупо разогнать тот же SQLite (в составе САСа) и общаться с базой меток только через него (через САС-приложение, первым взявшее монопольный доступ к данному хранилищу)
На разных компах?
Даже если и так, то это будет хуже. Все пользователи будут ломиться не на файловый сервер, а на несчастную пользовательскую машину. Конечно, можно запускать экземпляр программы на сервере, но это негибко.
А идея с SQLite интересная. Смотрю, всё больше и больше софта его используют. |
|
|
(0002616)
|
Parasite
|
20-05-2011 05:50
(edited on: 20-05-2011 05:52) |
|
>На разных компах?
Опционально. Никто не мешает приложению открыть определенный порт и смотреть им в сетку.
В общем и целом, это тема "приложение - одновременно и сервер, и клиент себя же". В этом случае не придется делать две отдельных функц.части, и потом их обе поддерживать.
>Даже если и так, то это будет хуже. Все пользователи будут ломиться не на файловый сервер, а на несчастную пользовательскую машину.
А чем "файловый сервер" отличается от "пользовательской машины" со стороны приложения? Только IP-адресом. :)
Вы уж определитесь - Вам либо тру-многопользовательность (со всеми сопутствующими расходами, включая временнЫе и интеллектуальные - сервер (желательно с бэкапами или рейдом), развертывание или настройка БД, разработка САСа) - либо относительно простенький вариант "для нищебродовъ", один из которых описан выше.
В случае единиц\десятков процессов САСа - вариант вполне имеет право на жизнь, как он имеет например в том же файрфоксе на локальной машине. 10-20 отдельных процессов файрфокса открыть - не проблема, и всё худо-бедно работает.
Для более глобальных задач, разумеется, нужны будут и более глобальные решения.
>А идея с SQLite интересная. Смотрю, всё больше и больше софта его используют.
В общем и целом, SQlite - _НЕ_ мультиюзверьное приложение. Это "эмулятор базовода для одного пользователя". Первый же запущенный экземпляр SQlite берет хранилище под себя монопольно как минимум на стадии записи в него, и далее - см.сообщение н.2 на этой странице. Несколько потоков [одного приложения] еще хоть как-то могут работать, так как движок базы все еще в этом едином приложении - а вот два совершенно отдельных экземляра будут драться за одну базу за право залочить ее под себя, а второй участник шоу будет либо кидаться еррорами, либо постоянно долбиться в хранилище на тему "не освободилось ли оно?"
При доступе к хранилищу в одно рыло (большинство совр.софта) - лепота и PROFIT, при многопользовательском - начинается тот же гимор что и с sml в САСе.
PS: SatMap юзает как раз Sqlite для кэша. Параллельная работа двух копий SatMap'а на одну базу КРАЙНЕ не рекомендуется самим автором прожки (а будучи проделана - вызывает кучи ерроров, проверено лично). :)
|
|
|
|
Нет. В базовом функционале такого не будет. Слишком уж специфичные требования и слишком много мороки для реализации нормальной предсказуемой работы этой фитчи. |
|
|
(0003250)
|
Tolik
|
22-07-2011 06:05
|
|
|