• Intersystems Caché: Globals API для .NET – прямой доступ к глобалам из C#
    0
    Эти библиотеки устанавливаются автоматически вместе с установкой Caché, они должны быть в той папке, куда вы установили саму СУБД, и дальше \dev\dotnet
  • Семафоры, или как разруливать доступ к ресурсам в DBMS Caché
    0
    Я так думаю там расшаренный LOCK, еще и HANG и циклическая обработка запросов.

    Большинство кода отвечает за логирование и генерацию тестовых данных, чтобы было в принципе понятно как работать с семафором.
  • Семафоры, или как разруливать доступ к ресурсам в DBMS Caché
    +1
    Простой инкремент какой-то глобальной переменной без дополнительных телодвижений не дает возможности ограничить доступ к какому-то ресурсу. Вернее инкремент его вообще никак не ограничивает, он просто увеличивает/уменьшает значение переменной. С его помощью мы можем получить «реальное» значение какой-то переменной в результате работы с ней нескольких процессов. Но мы не можем поставить процессы в очередь и обрабатывать их запросы только после того, как уже работающие процессы завершатся.

    В данном конкретном примере мы конечно можем
    инкрементировать глобаль ^Semaphor(Key) при логине и декрементировать при логауте
    но это нам не даст возможности ограничить доступ только 10 людьми одновременно и не поставит 11 (и так далее) человека в список ожидания.
  • Семафоры, или как разруливать доступ к ресурсам в DBMS Caché
    +3
    Судя по документации, если задать семафору имя по правилам именования глобальных переменных, то он будет записан в глобальную область имен и, соответственно, будет доступен в ECP
  • Intersystems Caché: Globals API для .NET – прямой доступ к глобалам из C#
    0
    И еще одно примечание для тех, кто будет пробовать использовать данный метод доступа к данным. При установке Cache с минимальными ограничениями по безопасности, логин и пароль при подключении к БД не проверяются
    myConn.Connect("User", "_SYSTEM", "SYS");
    Т.е. можно ввести абсолютно все что угодно и соединение будет установлено успешно.

    Чтобы исключить такое поведение надо либо при установке выбирать средний уровень безопасности, или настраивать доступа в Портале управления Cache.
  • Intersystems Caché: Globals API для .NET – прямой доступ к глобалам из C#
    0
    это такой side-эффект, что для значительных по нагрузке задач Caché относительно нетребовательна к ресурсам

    Это очень приятный «минус».
  • Intersystems Caché: Globals API для .NET – прямой доступ к глобалам из C#
    +3
    > Неплохая статья, про Globals раньше не слышал или не обращал внимания).
    GlobalsDB и Intersystems Cache — это две NoSQL СУБД от компании Intersystems. Про первую из них написано в трех статьях на Хабре, которые я привела в конце. Но если в GlobalsDB данные доступны только в виде глобалов с прямым доступом к ним, о котором собственно и идет речь в статье, то в Cache можно также получить еще и объектный доступ, и реляционный без каких-либо дополнительных телодвижений.

    > Не хватает наверное таблички с цифрами для 3 подходов, раз уж вы сравниваете скорость.
    Собственно говоря в этой статье я скорость не сравниваю и остальные два подхода никак не рассматриваю. Более того, я в самом начале написала, что эта статья для тех «кому, как и мне, с первого взгляда документация не дала полного понимания процесса». Но если говорить в принципе, то на тех примерах, которые я делала, прямой доступ работает быстрее всего. Хотя опять же, многое зависит от структуры данных, которые надо записать. С другой стороны, приложения с объектным/реляционным доступом можно запускать с любого компьютера на котором прописан DNS к БД, а при прямом доступе все должно быть на одной машине. Так что тут вопрос еще и в задачах, которые ставятся перед программой.

    > какие преимущества и недостатки использования Globals, по сравнению с другим СУБД?
    Зависит от того, с какими конкретно сравнивать :)

    Если с реляционными, то иногда даже реляционный доступ к Cache работает быстрее чем к другим СУБД. Еще один плюс с моей точки зрения — есть объектный доступ и возможность проектировать БД не в виде реляционных таблиц, а в виде классов со всеми вытекающими прелестями ООП и оперировать с данными как с объектами. Кроме того, не надо использовать ORM для перехода от реляционных данных к объектным (Hibernate и т.п.) — это все сделано разработчиком и заточено под конкретные типы данных, а их там много!

    Если сравнивать с объектно-ориентированными (документно-ориентированными), то у них зачастую отсутствует возможность реляционного доступа. Если уже существующее приложение надо перевести на нереляционную БД, то придется много переписывать для изменения метода получения данных. В случае с Cache надо просто поменять драйвер и при желании модифицировать запросы для ускорения получения данных.

    Также Cache заточена под работу на маломощных машинах с большими объемами данных. Ну и не стоит забывать про другие приятные «бантики» — наличие встроенного Business Intelligence модуля (с построением и отображением OLAP-кубов) и дополнительных продуктов для интеграции данных из разных приложений в одно хранилище.

    Это так, первое что пришло в голову. Конечно как и во всех системах, есть также и некоторые минусы. Для меня главный — это встроенный язык программирования, очень уж он непривычный.