0000745: Многопользовательский доступ к файлу меток (сложное решение, одновременно сидит несколько пользователей) - SASGIS

All Projects SAS.Планета Домен, сайт, форум, багтрекер Доработка карты (ZMP) Переводы и локализации Прочее

ID	Project	Category	View Status	Date Submitted	Last Update
0000745	SAS.Планета	Хотелка / Feature request	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
Product Version	110418

Summary	0000745: Многопользовательский доступ к файлу меток (сложное решение, одновременно сидит несколько пользователей)
Description	В продолжение хотелки 744. А вдруг возможно сделать по-настоящему многопользовательский доступ с минимумом телодвижений для разработчиков? Даже если и нет, будет хотелка на будущее. Конечно, SAS не база данных. И даже пользоваться средствами БД не будет ближайшие N лет, поскольку переход с файлового хранилища на базу - процесс нетривиальный и большинству не нужный. В принципе, можно сделать так: рядом с базой меток лежит файл-флажок (другой, не тот, что в 744 про блокировку). Пользователь, создавший изменение в метках, автоматически обновляет флажок. Программы всех пользователей во время работы должны постоянно мониторить время создания флажка, и когда оно изменяется, то перезагрузить с общего хранилища себе базу меток и сделать у себя же отметку, что флажок с временем создания таким-то отработан (удалять его нельзя - остальные пользователи тогда не увидят изменений). Схема несложная, но на практике чреватая тормозами у всех участников по каждому чиху кого-либо из них. Это надо смотреть и думать, как оптимизировать сей процесс. Возможно, кто-то придумает и другую схему, не такую прямолинейную.
Tags	доступ

Parasite 18-05-2011 17:55 administrator ~0002581	>можно сделать так: рядом с базой меток лежит файл-флажок (другой, не тот, что в 744 про блокировку). Пользователь, создавший изменение в метках, автоматически обновляет флажок. Программы всех пользователей во время работы должны постоянно мониторить время создания флажка, и когда оно изменяется, то перезагрузить с общего хранилища себе базу меток и сделать у себя же отметку, что флажок с временем создания таким-то отработан (удалять его нельзя - остальные пользователи тогда не увидят изменений). Попытка реализации тривиального sync - detected. На самом же деле можно тупо разогнать тот же SQLite (в составе САСа) и общаться с базой меток только через него (через САС-приложение, первым взявшее монопольный доступ к данному хранилищу). Учитывая то, что у среднестатистического хомяка меток немного, а разнесенных САСов - еще меньше, то метод вполне сработает. PS: именно это реализовано в FireFox например. Первый же запущенный процесс берет монопольное использование например букмарков, settings или там browsing_history - через Sqlite, а все последующие детектируют наличие первого и общаются только через него. В итоге - общие глобальные метки в виде конкретных единичных файлов, и никакого Sharing Violation. Перенес эту кучку баз на другой компьютер - считай, склонировал свой Файрфокс. Именно это сейчас преподносят как "FF Mobile Sync". :)

gpsMax 19-05-2011 11:41 manager ~0002594	> можно тупо разогнать тот же SQLite (в составе САСа) и общаться с базой меток только через него (через САС-приложение, первым взявшее монопольный доступ к данному хранилищу) На разных компах? Даже если и так, то это будет хуже. Все пользователи будут ломиться не на файловый сервер, а на несчастную пользовательскую машину. Конечно, можно запускать экземпляр программы на сервере, но это негибко. А идея с SQLite интересная. Смотрю, всё больше и больше софта его используют.

Parasite 20-05-2011 05:50 administrator ~0002616 Last edited: 20-05-2011 05:52	>На разных компах? Опционально. Никто не мешает приложению открыть определенный порт и смотреть им в сетку. В общем и целом, это тема "приложение - одновременно и сервер, и клиент себя же". В этом случае не придется делать две отдельных функц.части, и потом их обе поддерживать. >Даже если и так, то это будет хуже. Все пользователи будут ломиться не на файловый сервер, а на несчастную пользовательскую машину. А чем "файловый сервер" отличается от "пользовательской машины" со стороны приложения? Только IP-адресом. :) Вы уж определитесь - Вам либо тру-многопользовательность (со всеми сопутствующими расходами, включая временнЫе и интеллектуальные - сервер (желательно с бэкапами или рейдом), развертывание или настройка БД, разработка САСа) - либо относительно простенький вариант "для нищебродовъ", один из которых описан выше. В случае единиц\десятков процессов САСа - вариант вполне имеет право на жизнь, как он имеет например в том же файрфоксе на локальной машине. 10-20 отдельных процессов файрфокса открыть - не проблема, и всё худо-бедно работает. Для более глобальных задач, разумеется, нужны будут и более глобальные решения. >А идея с SQLite интересная. Смотрю, всё больше и больше софта его используют. В общем и целом, SQlite - _НЕ_ мультиюзверьное приложение. Это "эмулятор базовода для одного пользователя". Первый же запущенный экземпляр SQlite берет хранилище под себя монопольно как минимум на стадии записи в него, и далее - см.сообщение н.2 на этой странице. Несколько потоков [одного приложения] еще хоть как-то могут работать, так как движок базы все еще в этом едином приложении - а вот два совершенно отдельных экземляра будут драться за одну базу за право залочить ее под себя, а второй участник шоу будет либо кидаться еррорами, либо постоянно долбиться в хранилище на тему "не освободилось ли оно?" При доступе к хранилищу в одно рыло (большинство совр.софта) - лепота и PROFIT, при многопользовательском - начинается тот же гимор что и с sml в САСе. PS: SatMap юзает как раз Sqlite для кэша. Параллельная работа двух копий SatMap'а на одну базу КРАЙНЕ не рекомендуется самим автором прожки (а будучи проделана - вызывает кучи ерроров, проверено лично). :)

vdemidov 21-07-2011 05:29 manager ~0003227	Нет. В базовом функционале такого не будет. Слишком уж специфичные требования и слишком много мороки для реализации нормальной предсказуемой работы этой фитчи.

Tolik 22-07-2011 06:05 manager ~0003250	раз won't fix, то closed

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
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
08-08-2025 13:24	zed	Category	Хотелка => Хотелка / Feature request