排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
トランザクションIDへのロックと行ロック
TL;DR PostgreSQLのロックマネージャ 行ロック 行ロック待ち トランザクションIDへのロック トランザクション完了の順番待ち まとめ 参考 PostgreSQLが持つpg_lockシステムビューを使うと、PostgreSQLのロックマネージャが管理している情報を見ることができ、誰がどのようなオブジェクトに対し、どの種類のロックを取得しているのか、または取得できずに待っているのかを確認することができます。 PostgreSQLはロック対象のオブジェクトとして、テーブル、インデックス、行（タプル）やトランザクションIDがあります。実はトランザクションIDへのロックはPostgreSQLでは多用していて、pg_locksビューやサーバログでトランザクションID（やトランザクション）に対してExclusiveLockやShareLockの取得は見たことがある人も多いのではと思います。
【新機能】マイクロサービス間の連携を補助するためのサービスを追加します - GS2 Blog
みなさんこんにちは。GS2 CEO の丹羽です。 近日公開予定の新機能のお知らせをしたいと思います。 今回お知らせするサービスは2つで、どちらもGS2のマイクロサービス間を協調動作させるために重要な役割を果たす事になる機能です。 GS2-Lock これは名前の通り、排他処理を実現するための機能となっています。 機能としては非常に単純で、『特定のリソースに対してロックを取得する』という宣言と『特定のリソースのロックを解除する』という宣言の2つが主な機能です。 用途例 たとえば、GS2-Stamina でスタミナを回復するために GS2-Money で 課金通貨を消費する。というプロセスを例に考えてみましょう。 GS2-Lock が無い状態でこれを実現すると、『GS2-Stamina でスタミナを回復する』『GS2-Money で 課金通貨を消費する』という2つの操作はそれぞれ独立した操作にな
PostgreSQLのパーティショニング機能とLOCK TABLEの影響範囲の確認 - Qiita
PostgreSQL10のネイティブ・パーティショニング機能で作成されたパーティションが、テーブル単位のロック取得(LOCK TABLE)の影響をどのように受けるか確認する。 今回は、以下のシンプルなパーティションで確認する。 CREATE TABLE parent (i INT) PARTITION BY LIST (i); CREATE TABLE child1 PARTITION OF parent FOR VALUES IN (1); CREATE TABLE child2 PARTITION OF parent FOR VALUES IN (2); CREATE TABLE child3 PARTITION OF parent FOR VALUES IN (3); CREATE TABLE child4 PARTITION OF parent FOR VALUES IN (4);
5.4. 排他制御 — TERASOLUNA Global Framework Development Guideline 1.0.0.publicreview documentation
5.4.1. Overview¶ 排他制御とは、複数のトランザクションから同じデータに対して、同時に更新処理が行われる際に、データの整合性を保つために行う処理のことである。 複数のトランザクションから同じデータに対して、同時に更新処理が行われる可能性がある場合は、基本的に排他制御を行う必要がある。 ここで言うトランザクションとは、かならずしもデータベースとのトランザクションとは限らず、ロングトランザクションも含まれる。 Note ロングトランザクションとは データの取得とデータの更新を、別々のデータベーストランザクションとして行う際に発生するトランザクションのことである。 具体例としては、取得したデータを編集画面に表示し、画面で編集した値をデータベースに更新するようなアプリケーションで発生する。
Redisのsetnxを使ってマルチサーバ環境での Web API ロック機構を実現する | DevelopersIO
「これ、同時にリクエスト飛んできた場合って、どうなるの？」 「2つ登録されちゃいますね…」 はじめに Web APIは、リクエストを受け、処理を終えた後レスポンスを返します。モバイルアプリやウェブアプリとセットで開発しているとつい忘れがちになってしまいますが、同時に同じリクエストが飛んできた場合にどういう挙動をするか ということは常に考慮しておかなくてはなりません。「UI上同時にリクエストが送れないから問題なし」では Web APIの設計が不十分です。別の端末から同時に同じリクエストを送ることも可能ですので、UIとは切り離して考えるべきです。 さて、この状況、GETリクエストについては大きな問題にはならないでしょう。いくらリクエストが来てもサーバ側の状態に変化はないので、負荷対策だけしておけば大丈夫そうです。問題はPUTリクエストやPOSTリクエストといった、サーバ側のリソースに変化を及ぼ
長年の議論に終止符 -- MySQL/MariaDBのバックアップとロックの関係＋クラッシュセーフについて - interdb’s diary
よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。 オンラインバックアップに関するロックの正確な記述 より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
MySQLのロックについて - SH2の日記
JPOUG> SET EVENTS 20140907 | Japan Oracle User Group (JPOUG)に参加して発表をしてきました。IIJさまのセミナルームは窓からの眺めがすばらしいですね。JPOUGの運営メンバのみなさま、会場を提供してくださったIIJのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは「MySQLのロックについて」と題してネクストキーロックなどの説明をしました。プレゼンテーション資料と、調査のために作成したツールを公開します。 プレゼンテーション資料 (PDF) Lock Inspector 1.0 プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Lists: mysql: Re: InnoDB's inner workings + checkpoints 過去記事の訂正 @kami
SELECTなのにテーブルにロックが掛かる！〜InnoDBトランザクションにおけるINSERT INTO SELECT FROMの罠〜 - XOOPS専門-株式会社RYUS
SELECTなのにテーブルにロックが掛かる！〜InnoDBトランザクションにおけるINSERT INTO SELECT FROMの罠〜 カテゴリ : 技術全般 2010-10-14 19:37 MySQLのInnoDBはトランザクションが使えたり、行ロックが使えたりして、データの整合性の点でMyISAMに比べて優れています。 業務系アプリになると、データの整合性が重視されることも多く、トランザクションを使うことも増えます。 今回、そのトランザクションを使っていて、思いもよらないクエリがきっかけで、テーブルにロックが掛かってハマりました。 テーブル構造はこのような感じ...。 CREATE TABLE `working` ( `id` int(11) NOT NULL AUTO_INCREMENT, `col` int(11) NOT NULL DEFAULT '0', PRIMARY K
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JPAの同時実行制御とロック20140518 #ccc_r15 #jjug_ccc