Безопасно использовать объект TAdsSettings в основном потоке и объекты AdsQuery в других потоках?

Да, это сработает. Компонент TAdsSettings изменяет параметры в Advantage Client Engine (ACE), а с ISAPI будет загружен один экземпляр ACE, который использует все потоки.

Однако я бы не рекомендовал его. В зависимости от настроек, которые вы меняете, было бы разумнее просто напрямую обращаться к API ACE. Например, если вы только устанавливаете формат даты, имеет смысл устранить компонент TAdsSettings и просто вызвать AdsSetDateFormat60, который принимает дескриптор соединения. Избавление от компонента TAdsSettings устраняет множество вызовов для установки глобальных настроек ACE. Многие из этих вызовов должны иметь объект синхронизации, чтобы отключить все соединения, пока глобальное изменение. Это будет иметь негативное влияние на производительность, особенно в многопоточном приложении, таком как веб-приложение. Вместо этого выполняйте вызовы, которые работают с указанным дескриптором соединения.

Вы можете получить дескриптор соединения, указав свойство TAdsConnection.Handle или вызывая метод TAdsQuery.GetAceConnectionHandle.

Убедитесь, что AdsQueries использует Synchronize для прямого доступа к TAdsSettings (или использует систему обмена сообщениями для связи между рабочими потоками и основным потоком вместо прямого доступа), если они не находятся в основном потоке (то есть System.MainThreadID <> Windows.GetCurrentThreadID)

Я также задал этот вопрос в группе новостей: devzone.advantagedatabase.com, Advantage.Delphi

Для полноты я добавлю еще один вопрос / ответ из остальной части этого потока:

Вопрос (я):

Многие запросы в потоках в настоящее время не привязаны к объекту TAdsConnection. Я планирую создать соединение для каждого потока для этих «сиротских» запросов, но это большое приложение, и это потребует времени. Я также уверен, что единственным свойством не по умолчанию в объекте TAdsSettings является набор типов серверов, который также может быть установлен в компоненте соединения, поэтому, когда все запросы связаны с соединениями, компонент настроек не понадобится. Я буду рассматривать API-интерфейсы напрямую в качестве альтернативы.

Тем временем у меня есть вопрос о потоковой обработке и запросах без назначенного компонента соединения. Я отметил из файлов справки, что если запросы в нескольких потоках совместно используют один объект соединения, запросы будут запускаться последовательно, а не одновременно. С объектом соединения в каждом потоке это не должно быть проблемой, но мне интересно, какие запросы не имеют назначенного объекта соединения. Будут ли они считаться находящимися на независимых соединениях с точки зрения параллелизма многопоточности или они будут считаться находящимися в одной и той же связи и, следовательно, должны уступать друг другу?

Ответ (Джереми):

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

Таким образом, из ответа Джереми лучше всего создать по крайней мере один объект TAdsConnection для каждого потока и убедиться, что к нему привязаны все запросы, иначе может произойти сериализация.