2

データベース クエリの結果をアドホックなクライアント リクエストに提供しようとしているが、個々のクエリごとに接続を開きたくない。私はそれを正しく行っているかどうかわかりません。

現在の解決策は、「サーバー」側で次のようなものです（明確にするために大幅に削減されています）：

import rpyc
from rpyc.utils.server import ThreadedServer
import cx_Oracle

conn = cx_Oracle.conect('whatever connect string')
cursor = conn.cursor()

def get_some_data(barcode):
    # do something
    return cursor.execute("whatever query",{'barcode':barcode})

class data_service(rpyc.Service):
   def exposed_get_some_data(self, brcd):       
       return get_some_data(brcd)


if __name__ == '__main__':
   s = ThreadedServer(data_service, port=12345, auto_register=False)
   s.start()

これでしばらくは問題なく動きます。ただし、プログラムがクラッシュすることがありますが、これまでのところ、いつクラッシュするかを追跡できませんでした。

私が確認したいのは、data_service クラスの外部でデータベース接続がどのように作成されるかを確認することです。これ自体が問題を引き起こす可能性はありますか？

どうもありがとうございました。

4

1 に答える 1

1

問題は、クラスの外で接続を作成していることではないと思います。それで問題ありません。

問題は、カーソルを1つだけ作成して長時間使用していることだと思います。これは、私が理解している限り、カーソルの使用方法ではありません。

カーソルを手動で作成せずに使用できconn.executeます。これは、データベースの使用方法には問題ありません。私の記憶が正しければ、舞台裏でこれにより各 SQL コマンドに対して新しいカーソルが作成されます。でこれを自分で行うこともできget_some_data()ます。新しいカーソルを作成し、一度使用してから、データを返す前に閉じます。

長期的には、サーバーをより堅牢にしたい場合は、データベース操作が失敗した場合や接続が失われた場合に備えて、エラー処理を追加する必要があります。

最後の注意: 基本的に、非常に基本的なデータベース プロキシ サーバーを作成しました。おそらく、これにはすでにさまざまな既存のソリューションがあり、遭遇する可能性が高い多くの問題を既に処理しています。少なくとも既存のソリューションの使用を検討することをお勧めします。

于 2011-11-06T10:50:53.050 に答える