なかったらINSERTしたいし、あるならロック取りたいやん?位置情報を使ったサービス「スマポ」をPostgreSQLで作ってみた db tech showcase 2013 TokyoYoshiyuki Asaba
挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary
なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ！！— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめに これは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
QA＠IT サービス終了のお知らせ - ＠IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
YappoLogs: ExclusiveLock::Guard という排他ロック簡単にやるモジュール書いた
ExclusiveLock::Guard という排他ロック簡単にやるモジュール書いた ファイルを使って排他ロックするには、適当にロックファイルを作って flock $fh, LOCK_EX とかすると思います。 flock で使ったファイルハンドルが close されたら自動的に unlock されるので、最初っから Guard な感じなんだけどロック用のファイルも一緒に消したいので ExclusiveLock::Guard ってのを作った。 use ExclusiveLock::Guard; my $lock = ExclusiveLock::Guard->>new('/tmp/megazaru.lock'); って書くだけで $lock が生きてる間はロックかかってて、ロック外れたらファイルも一緒に消してくれるというだけの物。 ノンブロッキングなインターフェィスが欲しければ use E
InnoDBのネクストキーロックによるデッドロックの例 - iakioの日記
あまりMySQLのことは自信ないですが。 一見問題なさそうに見える操作でデッドロックしてしまうケースがあったので動画にしてみました。 SELECTしてみて「有ればUPDEATE、無ければINSERT」や、あるいは「有れば何もせず、無ければINSERT」を行ないたい場合に、SELECT FOR UPDATEして無ければINSERTとしてしまうと、動画の最初の例のようにデッドロックしちゃいます。存在しない行に対してSELECT FOR UPDATEするとちょっと広めに行ロックがかかってしまう感じでしょうか。 「有ればUPDATE、無ければINSERT」であれば、INSERT ... ON DUPLICATE KEY UPDATEを使うのが良さそう。「有れば何もせず、無ければINSERT」なら、いきなりINSERTしてみて一意制約違反ではじいてもらうのがいいのかな。 動画の2つめの例は、i =
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
