問題タブ [zodb]

サーバーとクライアントがあります。

クライアントがリクエストを送信します。a-1リクエストには、 、a-2、b-1などの特定のキーが関連付けられていb-4ます。

同じキーに対する 2 つのリクエストが同時に来ると、同じデータ構造が変更されているため、競合エラーが発生します。

同じキーの 2 つの要求を一度に送信しないようにクライアントを適応させることができます。ただし、このシステムが複数のクライアントでも動作することを望みます。クライアントがサーバーに送信するものを調整するのはばかげているようです。代わりに、特定のキーが既に変更されている場合、同じキーを持つ他のリクエストが完了するまで、サーバーが特定のキーのリクエストを単純にブロックするようにしたいと思います。

この目的のために、ロック システムを作成しました。サーバー上の関数の開始時に、次のことを行います。

ここKEY_LOCKSで、キーをthreading.Locks にマッピングする dict です。その後、永続データ構造を変更するコードに従います。

私が想定しているのは、すでに処理されているキーのリクエストが来た場合、ロックを取得するときにブロックされるということです。以前のリクエストがすでにコミットされている(競合エラーが発生していない) 場合にのみ、新しいリクエストが再開されます。ロックが取得されるまで、要求は競合することはありません。

ほとんどのリクエストは正常に機能します。

ただし、ロックが機能しているように見えても、同じキーが送信された場合にはまだ問題があります。

そして、リクエストが再試行されます。q-q lockは、コミットが成功した後にのみ取得されたことに注意してください。

何を与える？このシステムが競合エラーを防げないのはなぜですか? 私の仮定はどこが間違っていますか？

編集:まあ、transaction.get().addAfterCommitHook(after_commit_hook)私が入れた行の前にtransaction.begin()、それは機能します。私の人生では、理由がわかりません。行の前に、transaction.begin()私のコード全体は次のとおりです。

これは私の問題を解決しますが、私はまだ知りたいので、それを答えとして入れていません:直前に新しいトランザクションを開始しないと、競合エラーが発生するのはなぜですか?

私はいくつかの PloneFormGen 作業を行っています。現在、PloneFormGen は入力されたフォーム エントリを関連する列情報なしのタプルとして内部的に保存します。新しい列 (フォーム フィールド) が追加されると、既存のデータは無効になります。

これは、入力された列の順序と列 ID の両方を保持する順序付けられた辞書にデータを格納することを簡単に回避できます。

ZODB には、順序付けられた辞書と同等のデータ型がありますか? 可能であれば、一致する API (Python dict のようなアイテムの操作とアクセス) でも可能ですか?

新しいマシンに ZODB をインストールしようとしています。別のマシンにある同じインストールを一致させたい (最新の ZODB は easy_install では正しくインストールされない)。新しいマシンにインストールしたいオリジナルの easy-install.pth があります。

これらの正確なファイルを新しいマシンにインストールする方法はありますか? フォルダーを新しいマシンにコピーしようとしましたが、python はモジュールを認識しません。

Zope2セッションのドキュメント：「競合エラーはZopeによって自動的に再試行され、エンドユーザーには表示されません。」

ただし、トラフィックの多い展開（4つのクライアントで共有されるZEO上のセッションデータの一時ストレージ、同じセットアップのzopeインスタンス）には最適なセットアップがあると思いますが、エンドユーザーは依然としてDatabaseConflictErrorsを受け取ります。

メールリストを検索すると、これはZOPがOOBTreeに基づいてセッションデータを実装する際の一般的な問題のようです。repoze.sessionの使用を提案する人もいますが、2009年以降はサポートされていません。

BTree / TransientObjectの競合エラーを修正するための他のアプローチはありますか？session_dataのデフォルト設定（データオブジェクトのタイムアウト値、タイムアウトの解決、サブオブジェクトの最大数）を変更する必要がありますか？

オブジェクトを保存するたびに、インスタンスログに次の警告が表示されます。

実際、節約には時間がかかります。これが出力される場所にpdbを配置すると、トランザクションのコミット中にトリガーされ、PersistentMappingが次のタイプで記述されていることが実際に示されます。

サイト内のコンテンツオブジェクトごとに1つのエントリがあるようです。これはコミット中に発生するため、そのマッピングがどこに保存されているかわかりません。

誰かがそれが何であるかについての指針を持っていますか？

どうもありがとう！アレックス

でデプロイされた単純なFlaskアプリでflask-zodbを使用する際に問題が発生しました。たとえば、デフォルトの設定など、DBを使用しようとするたびに次のようになります。mod_wsgi

または次のようなビューで：

次のエラーが発生しました：

アプリケーションは開発環境で正常に動作し、次のように設定しようとしたので、プリミッションの問題はないと思います。

そして、同じ例外が発生します。なぜこれが起こるのか、そしてこの種のエラーを回避する方法がわかりません。何か案は？

私は Python + ZOPE/ZODB/Repoze BFG (頭字語はすべて非常に混乱します) + ペーストを使用しています。

次のようにして実行できるpasterシェルがあります。

すべて正常に動作します。ただし、オンになる監視機能がたくさんあります-デバッグ情報を標準出力に出力するスレッド-シェルを起動したばかりのときに実行する必要はありません。起動コードがシェルで実行されているかどうかを何らかの方法で検出することは可能でしょうか? したがって、コードがシェルがオンになっていないことを検出すると、それらのスレッドを開始し、シェルがオンになっている場合は開始しません。

次のコードによって生成されたデータを処理しようとしています。

ディクショナリは大きいため (10000 個のキー X 10000 個のリストにそれぞれ 3 つの要素がある)、メモリに保持するのは困難です。キーと値のペアが生成されるとすぐに（リストの形式で）保存するソリューションを探していました。ZODB を Btree と組み合わせて使用​​することをお勧めします。

これが単純すぎる場合はご容赦ください。私の質問は、transaction.commit()データをコミットするためにいつ呼び出す必要があるかということです。内側のループの最後で呼び出すと、結果のファイルが非常に大きくなります (理由はわかりません)。ここにスニペットがあります：

両方のループの外で呼び出すとどうなりますか? 何かのようなもの：

transaction.commit() を呼び出すまで、すべてのデータがメモリに保持されますか? 繰り返しますが、理由はわかりませんが、これによりディスク上のファイル サイズが小さくなります。

メモリに保持されるデータを最小限に抑えたい。ガイダンスをいただければ幸いです。

ただし、同様のタイプの質問が他の人から尋ねられています。here、しかしそれらはわずかに異なり、実際には私の問題を解決できなかったので、ここでもう一度行きます。

N 個のリスト (N>20,000) があり、各リストには M 個のリスト ( M >20,000) が次のように含まれています (データはダミーです)。

データはソートされていません。しきい値のリストを 1 つずつ反復処理します。たとえばThreshold =[2, 3, 5, 7, 8]、しきい値が中央の要素に適用される場合、すべてのキーについて、しきい値より大きいすべての要素を抽出します。たとえば。Threshold = 2私が上に書いたデータによると、

他のしきい値についても同様です。リストが多すぎるため、並べ替えが多くのオーバーヘッドに寄与しているため、回避したいと考えています。Pythonでこれを行う最適な方法は何ですか?. もう 1 つの重要な点は、私は自分でデータを構築しているので、最初にデータを格納するためのより良いデータ構造がある可能性があるということです。私は現在、ここで提案されたコンテナPersistentList内の形式でデータを保存しています。以下は、それに使用されるコードのスニペットです。BtreeZODB

それを行うための最も効率的な方法について何か提案はありますか? 最初にソートするのが本当に最適な方法ですか?

hereの提案に従って、次のコードで作成された ZODB を使用してデータを保存しました。

今、私は（別のモジュールで）（1）保存されたデータを変更し、（2）それを並べ替えたいと思っています。以下は私が使用していたコードです：

ただし、値を編集するために使用されるコードは、すべてのメモリを使い果たしています (決して並べ替えを行うことはありません)。これがどのように機能するかはわかりませんが、コードに何かひどく問題があり、ZODB がすべてをメモリに取り込んでいるため、問題が発生しているように感じます。メモリの問題に遭遇することなく、ZODB に格納された要素の置換と並べ替えなど、望ましい効果を達成するための正しい方法は何でしょうか? また、コードは非常に遅いです。それを速くするための提案はありますか?

[注: これらの変更をデータベースに書き戻す必要はありません]

connection.cacheMinimize()編集内部ループの後にコマンドを追加することでメモリ使用量が少し改善されたようですが、しばらくすると RAM 全体が消費され、困惑しています。