問題タブ [table-locking]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
mysql - ストアド プロシージャ内での MySQL InnoDB テーブルのロック
MySQL がストアド プロシージャ内でのテーブル ロックを許可しないのはなぜでしょうか。
ストアド プロシージャ内に次の SQL ステートメントがあります。
commentそのため、最初の SQL ステートメントで選択された行数が実際に更新された行数と異なる可能性があるため、テーブルへの書き込みを防ぐためにテーブルをロックする必要があります。
python - Python & Postgres: psycopg2.connect はテーブルをロックしますか?
ETL (抽出、変換、読み込み) を実行する Python スクリプトを実行しており、すべての psql クエリを 1 つのトランザクションに入れています。トランザクションは次のとおりです。
q4 を実行するとテーブルがロックされることはわかっていますが、トランザクション全体 (接続からコミットまで) でテーブルがロックされるかどうかはわかりません。
テーブルがロックされているかどうかをテストする方法はありますか? 現在、データはあまりありません (約 100 行)。
どうもありがとう！
php - 複数のプロセスから同じレコードを更新していないことを確認するにはどうすればよいですか? テーブルロックは必要ですか?
MySQL データベースをバックエンド (PHP からアクセス) として使用するプロジェクトに取り組んでいます。ときどき、行を選択して操作を行い、データベース内のレコードを更新します。
別のユーザーが最初の選択の直後に同じ行で同様のプロセスを開始した可能性があり、その変更によって最初のユーザーが行った変更の一部が上書きされる可能性があるのではないかと心配しています (2 番目のユーザーの選択にはまだそれらの変更が含まれていないため)。
これは実際の問題ですか？テーブルをロックする必要がありますか?これはアプリケーションのパフォーマンスに深刻な影響を与えませんか? 他の解決策はありますか？
私の情報を徹底するために、同じデータを変更している可能性のある CRON ジョブもいくつか実行しています。
ありがとう！
ios - JIRA Mobile Connect for ios で双方向通信を行うと、sqlite のロックが原因でアプリがクラッシュする
「tip」という名前の最新のタグを使用しており、JIRA オンデマンドを使用しています。
JIRA モバイル コネクトを iOS アプリに組み込みましたが、動作がおかしくなりました。つまり、無限ループに入り、アプリがハングします。デバッグ モードをオンにして、もう少し詳しく調べたところ、この問題の原因は sqlite データベース テーブルがロックされていることにあることがわかりました。
イベントのシーケンスは次のようになります。
- 初めてアプリを起動しました
- JIRA モバイル コネクトを使用して問題を作成しました
- アプリをシャットダウンしました
- Web インターフェイス経由で JIRA online にコメントを追加して問題を更新しました (双方向通信シナリオをシミュレートするため)。
- iOSアプリを再起動しました
- JMC は、 https: //xxxx.atlassian.net/rest/jconnect/1.0/issue/updates?sinceMillis=1408380024967&uuid=9371F70F-12CD-47EC-AB3E-4B0398FF453E&apikey=YYY & project= AAA- を使用して JIRA REST API から更新を取得します。ステップ 4 で行った更新を見つけることができる
- 変更が見つかったので、既存の 2 つのテーブルを削除してスキーマを再作成しようとするロジックを持つメソッドを
JMCIssueStore.m呼び出します。updateWithData[self createSchema:YES] - 1 回目のテーブル ドロップ試行
[db executeUpdate:@"DROP table if exists ISSUE"]で、データベース テーブルがロックされていることが検出され、JMC はこのステートメントの実行を再試行する無限ループに入ります。
Atlassian Q&A ポータルまたは Web でこれに対する回答を見つけることができません。これを使用している他の人が同じ問題を抱えているはずであるか、統合しようとして明らかに間違ったことをしたので、驚くべきことだと思います。
誰かがこれまたは似たようなことに遭遇しましたか? これは、私が JIRA Mobile Connect を使用している重要な機能の 1 つであるため、JIRA モバイル コネクトをデバッグする価値があるのか、それともあきらめて最初からやり直す価値があるのかを本当に判断する必要があります。
mysql - InnoDB と分離レベル - 反復可能な読み取りは悪いことではありませんか?
InnoDB's 私は分離レベルについて読んでいましたが、それはほとんどの場合理にかなっていますが、私が得られないのはなぜunrepeatable reads悪いことなのですか? 逆であってはいけませんか？
例えば：
たとえば、製品を販売するための在庫列があり、誰かが商品を購入するたびに列から 1 つの商品を取得するとします。Repeatable readまたはserializable分離レベルを使用すると、データの整合性が損なわれませんか?
例えば：
更新を実行するときに正しい値を使用しない限り?