È sicuro utilizzare l'oggetto TAdsSettings nel thread principale e gli oggetti AdsQuery in altri thread?

Question

Ho un'applicazione Win-CGI che sto attualmente convertendo in ISAPI.

L'applicazione utilizza i discendenti di TDataset per Extended Systems Advantage Database Server.

Poiché può esserci solo un'istanza di un oggetto TADSSettings, questo deve essere nel thread principale.

Gli oggetti TAdsQuery sono necessari nei thread di richiesta.

Questo funzionerà - vale a dire, le Adsqueries nei thread di richieste raccoglieranno le impostazioni globali dall'oggetto AdSsettings nel thread principale e questo sarà sicuro?

Answer 1

Sì, funzionerà.Il componente TAdsSettings modifica le impostazioni in Advantage Client Engine (ACE) e con ISAPI verrà caricata un'istanza di ACE utilizzata da tutti i thread.

Non lo consiglierei, tuttavia.A seconda delle impostazioni che stai modificando, avrebbe più senso chiamare direttamente le API ACE.Ad esempio, se stai impostando solo il formato della data, è più sensato eliminare il componente TAdsSettings e chiamare semplicemente AdsSetDateFormat60, che accetta un handle di connessione.L'eliminazione del componente TAdsSettings elimina molte chiamate per configurare le impostazioni globali ACE.Molte di queste chiamate devono avere un oggetto di sincronizzazione per mantenere tutte le connessioni disattivate mentre il globale viene modificato.Ciò avrà un impatto negativo sulle prestazioni, soprattutto in un'applicazione multi-thread come un'applicazione web.Effettua invece chiamate che operano sull'handle di connessione specificato.

È possibile ottenere l'handle di connessione facendo riferimento alla proprietà TAdsConnection.Handle o chiamando il metodo TAdsQuery.GetAceConnectionHandle.

Answer 2

Assicurati che AdsQueries utilizzi Synchronize per accedere direttamente a TAdsSettings (o utilizzi un sistema di messaggistica per comunicare tra i thread di lavoro e il thread principale invece di accedere direttamente) se non si trovano nel thread principale (ad es. System.MainThreadID <> Windows.GetCurrentThreadID)

Answer 3

Avevo anche posto questa domanda nel newsgroup:devzone.advantagedatabase.com, Advantage.Delphi

Per ragioni di completezza, aggiungerò ulteriori domande/risposte dal resto del thread:

Chiedimi):

Molte delle query nei thread non sono attualmente collegate a un oggetto TADSConnection.Ho intenzione di creare una connessione per ogni thread per queste domande "orfane" da utilizzare, ma è una grande applicazione e questo richiederà tempo.Sono anche abbastanza sicuro che l'unica proprietà non default nell'oggetto TADSSettings sia il set di tipi di server, che può anche essere impostato nel componente di connessione, quindi una volta che tutte le query sono collegate alle connessioni, il componente delle impostazioni non sarà necessario.Cercherò di chiamare l'API di Impostazioni direttamente come alternativa.

Nel frattempo, ho una domanda sul threading e sulle query senza componente di connessione assegnata.Dai file di aiuto ho notato che se le query in più thread condividono un singolo oggetto di connessione, le query verranno eseguite in serie anziché contemporaneamente.Con un oggetto di connessione in ogni thread, questo non dovrebbe essere un problema, ma mi chiedo delle domande che lo fanno non Avere un oggetto di connessione assegnato.Saranno considerati su connessioni indipendenti dal punto di vista della concorrenza multithreading, o saranno considerati sulla stessa connessione e quindi dovranno cedere tra loro?

Risposta (Jeremy):

Dovrai affrontare questo problema.Cercheranno solo un elenco globale di connessioni per trovarne uno con lo stesso percorso e useranno quella connessione.Non va bene in un'applicazione multi-thread.

Pertanto, dalla risposta di Jeremy è meglio creare almeno un oggetto TAdsConnection per ciascun thread e assicurarsi che tutte le query siano ad esso allegate, altrimenti potrebbe verificarsi la serializzazione.