現在、マルチスレッドサーバーアプリケーションで作業中です。データアクセスにFiredacを使用する予定です。ここに提供されているドキュメント:http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Multithreading_(FireDAC)から、同じTFDConnection
および/またはTFDQuery
に複数のスレッドから同時にアクセスしないでください(代わりに、これらのオブジェクトはスレッドごとに作成する必要があります)。マルチスレッドアプリケーションでのFiredacの使用
したがって、前のリンクに示した例では、TFDConnection
とTFDQuery
をTThread
オブジェクトに集中しています。しかし、私の場合、私はスレッドの作成(サーバー環境によって管理される)のコントロールを持っていません。このアプローチは有効な
procedure TAPMFiredacTemplate.executeSQL(sql:string);
var
oConn: TFDConnection;
oQuery: TFDQuery;
begin
oConn := TFDConnection.Create(nil);
oQuery := TFDQuery.Create(nil);
try
oConn.ConnectionDefName := self.ConnectionDefinitionName;
oConn.Connected := True;
oQuery.Connection := oConn;
oQuery.Open(sql);
while not oQuery.Eof do
begin
// process query
oQuery.Next;
end;
finally
if assigned(oQuery) then
begin
oQuery.Close;
oQuery.Free;
end;
if assigned (oConn) then
begin
oConn.Connected := False;
oConn.Free;
end;
end;
です:私は、したがって、潜在的に複数のスレッドから呼び出すことができる手続きの寿命に私のTFDConnection
とTFDQuery
オブジェクトのライフサイクルを制限するのですか? TFDQuery
オブジェクトを体系的に作成すると、パフォーマンスが低下しますか?
注:パフォーマンスを向上させるために、プライベートプール接続定義(TFDConnection
で使用)を使用する予定です。だから私はTFDConnection
を解放しても私の理解から、物理的な接続が破壊されるのではなく、プールに返さ:
oParams := TStringList.Create;
oParams.Add('Database=localhost:c:\apm\databases\mydb.FDB');
oParams.Add('User_Name=xxxxx');
oParams.Add('Password=xxxxxx');
oParams.Add('Pooled=True');
FDManager.AddConnectionDef('Firebird_Pooled','FB',oParams);
FDManager.Active := True;
最初のアプローチのためのパフォーマンスペナルティがあります。 [接続プーリング](http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Multithreading_(FireDAC)#Connection_Pooling)に続きます。 [例題](http://docwiki.embarcadero.com/CodeExamples/Tokyo/en/FireDAC.Pooling_Sample)を確認することができます。 – Victoria
私は 'FDManager'を使って事前に接続プールを作成し、そのプーリングされた接続を自分の手続きで使用することを考えていました(補足を参照)。つまり、私がTFDC接続を作成/解放しても、物理的な接続やプールからの接続です。これにより、パフォーマンスが向上します。しかし、私は 'TFDQuery'を最適化するために何ができるのかよく分かりません。 – BigONotation
クエリを準備することは別の高価な操作になります。サーバーがキープアライブの種類の接続をサポートしている場合は、クエリオブジェクトを作成し、クライアントの接続時にクエリを準備し、切断時にクエリを破棄します。各リクエストは、準備されたクエリーオブジェクト(コンテキストクラスによって参照される)で処理できます。 – Victoria