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

Question

У меня есть приложение Win-CGI, которое я сейчас конвертирую в ISAPI.

Приложение использует потомков TDataset для сервера баз данных Extended Systems Advantage.

Поскольку может быть только один экземпляр объекта TAdsSettings, это должно быть в основной теме.

Объекты TAdsQuery необходимы в потоках запросов.

Будет ли это работать - то есть будет ли AdsQueries в потоках запросов выбрать глобальные настройки из объекта AdsSettings в главном поток, и это будет потокобезопасным?

Answer 1

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

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

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

Answer 2

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

Ради полноты я добавлю еще вопрос / ответ от этой ветки:

Вопрос (Я):

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

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

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

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

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

Answer 3

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