Spring3.1概要 データアクセスとトランザクション処理
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall ) Hironobu Isoda
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall ) Hironobu Isoda
Quorum - Wikipedia
quorumとは分散システムにおいて、分散トランザクションが処理を実行するために必要な最低限の票の数である。quorumベースの技術は分散システムにおいて、処理の整合性をとるために実装される。 分散データベースシステムにおけるquorumベースの手法[編集] quorumベースの投票はデータベースレプリケーションの制御手法として使うことが出来る。[1] また、ネットワークパーティショニング下でのデータベーストランザクションアトミック性を保証するコミット手法としても使用できる。[1] コミットプロトコルにおけるquorumベース投票[編集] 分散データベースシステムにおいて、トランザクションは複数サイトにおいて処理を実行している場合がある。アトミック性は全ての分散トランザクションがアトミックであることを要求するため、そのトランザクションも全てのサイトにおいて、コミットあるいは中止のいずれかの
Schedule - CMU 15-721 :: Advanced Database Systems (Spring 2017)
Course Introduction and History of Database Systems M. Stonebraker, et al., What Goes Around Comes Around, in Readings in Database Systems, 4th Edition, 2006 (Optional) A. Pavlo, et al., What's New with NewSQL?, in SIGMOD Record (vol. 45, iss. 2), 2016 (Optional) In-Memory Databases H. Garcia-Molina, et al., Main Memory Database Systems: An Overview, in IEEE Trans. on Knowl. and Data Eng., 1992 S.
前回の「送金のトランザクション処理パターン」では、EntityGroupにまたがるトランザクション処理について簡単に紹介しました。 様々なコメントいただきまして(ありがとうございます)、どうやら「Distributed Transactions on App Engine - Nick's Blog」のやり方が非常に優れているようですので、今回は「送金のトランザクション処理パターン」で紹介した手法に最適化を施して、Nickさんのやり方に近付けてみようと思います。 今回紹介する最適化は、前回のような「狭い範囲のACIDトランザクション」と「べき等性による処理の伝搬」を組み合わせた分散トランザクション一般に適用できそうな手法です。そんなに大層なことはしていませんが、例によってまだ構想段階ですので、また至らない点があればご指摘いただければ幸いです。 おさらい 送金のトランザクション処理パターンで
Cicada：Dependably Fast Multi-Core In-Memory Transactions - 急がば回れ、選ぶなら近道
Cicada: Dependably Fast Multi-Core In-Memory Transactions https://www.cs.cmu.edu/~hl/papers/cicada-sigmod2017.pdf SIGMOD2017で発表されている。現状の分散OLTPのアーキテクチャをうまくまとめて、欠点をうまくカバーアップし、言って見れば次世代MVCCの一つの形を提示している。その上で、現在世界最高のパフォーマンスを叩き出している。現時点で世界最速DB（ただし自称）。 現状の分散OLTPは大きな流れは、SILO/Foedus/MOCC/等のOCC系、すなわち2PLをベースにした実装で理論上はmonoversionでのserializableの実現を行っている方式と、Hekaton/HyPer/Bohm/ERMIAといったMVCC系、すなわちMVTOの派生をベースにしてmu
_ 続ACIDからBASE 以前、acmqueueのBASEに関する記事の前半だけを勝手翻訳したが、続きをwinplusさんが翻訳してくれた。 実のところ、2フェーズコミットという技術は早すぎた自動化だと思う。えらく大層なことと複雑な仕組みではあるけれど、さっきまでオンラインだったシステムは直後もオンラインだろうという程度のあやふやな確信に頼って自動化しているだけのものだ。 よく似たシステムに、同時期にでてきたRPC（ORPCもそうだ）がある。 前提が高信頼性が確保できるクリーンルーム内の複数のノードから構成された分散システムだとしか思えない。それにしてもマシンは落ちるしネットワークは切れる。2フェーズコミットは、絶対に通信が可能だということと相手のプロセス（マシン）が落ちないことを前提としたシステムだという矛盾がある。SYNに対するACKを2時間待ってしまえばすでに成り立たないのだ。 早
ロックがわからない。MySQL InnoDBの行レベルロックを読んだけど、イマイチわからない。というわけで、社内の勉強会で知ったことをまとめてみる。 FOR UPDATEかLOCK IN SHARE MODEによって、そのトランザクション中に走る別画面でのクエリの処理のタイミングが異なる。 FOR UPDATEによるロック まずは画面Aで接続が行われ、トランザクションが開始され、SELECT文が発行されたとする。 [画面A] BEGIN; // トランザクションA開始 SELECT * FROM users WHERE id = 1 FOR UPDATE; COMMIT; // トランザクションA終了 そしてトランザクションAの開始後〜終了前に画面B〜Dがクエリを発行したとする。 ちなみにトランザクションを開始しておかないとFOR UPDATEを書いても画面Aでのロックが始まらないので要注
DBIx::TransactionManager
というのを書きました。 https://github.com/nekokak/p5-DBIx-TransactionManager まぁ、DBIx::Skinnyで使っているトランザクションの仕組みを別モジュールに切り出した感じです。 use DBI; use DBIx::TransactionManager; my $dbh = DBI->connect('dbi:SQLite:'); my $tm = DBIx::TransactionManager->new($dbh); { my $txn = $tm->txn_scope; $dbh->do("insert into foo (id, var) values (1,'baz')"); { my $txn2 = $tm->txn_scope; $dbh->do("insert into foo (id, var) values (
#ajn4 で発表したスライド。 app engineでのトランザクションでビルディングブロックとなることを期待したパターン集。Read less
CakePHP トランザクションを使う
4/23 19:16にちょっと更新。app_modelに定義しないで、いきなりモデル->commit()やモデル->rollback()は偶然動いているような気がしている点について追記。 久々にトランザクションを使うよ。環境はCakePHP1.2とMySQL4.1。 事前準備 MySQLのデータベースもしくは処理対象テーブルが、MyISAMではなく、InnoDBである必要がある。 MyISAMのままで、トランザクションのコマンドを発行しても、ロールバックできない。 今どのような形式になっているかは show table status; を実行すれば分かる。ここでMyISAMと表示されている場合は alter table hoge type=InnoDB として形式を変更することができる。 もちろんテーブル作成時にInnoDBを指定することもできる。 create table foobar
トランザクションとは何か - Qiita
イントロダクション これは@kumagiが一人でトランザクション技術に関する話をまとめていくアドベントカレンダーである。 トランザクション技術は多岐にわたり、複雑に絡み合い、DBの中で巨大な密結合コンポーネントを生み出している。そのためその中身を語るアドベントカレンダーも完全に順序付けて章立てしていくのは難しい。そのため様々な側面から一日に読めそうな文量の記事毎にまとめてアドベントカレンダーとするので、25日も話題が持つのかはさておき必ずしも記事の区切りは技術としての区切りの良さとは関係がない。 しかも初めの数日はトランザクションが実現する並行制御の理論的側面についての整理を淡々と述べるので退屈になること請け合いだけれど、可能な限り図解しながら説明を尽くすのでわからない所は容赦なくはてブやTwitterなどで書いて貰えたら適宜加筆修正をするつもり。 アドベントカレンダーを書くにあたって参考
スクラム風に進めているけど，アジャイルだっていう意識は薄い．計画立てて計画通りに進める−−−しごく当たり前のことを当たり前にやってるので，従来型と違うという意味でアジャイルを引用するのは，なにか本質をくらませているように思う． どっちかというと従来型という名の元，実の無い作業を盲目的にやってただけなんじゃないかなぁと．「WBSだとか週報だとか面倒な割に役に立ってるかどうかわからん」と思っている人にはウケが良い． WBSが悪いってんじゃなくて，動機付けがちゃんと説明できてないだけなんだろなと．そいった事もあって，スクラムや見える化はチームビルディングの方法かなって思う． リーダの思惑 今参加してるメンバが他所のプロジェクトやりたくない！！って思うようになったら，オレの勝ち．:-D やっとできた．以下，その設定方法． 続きを読む 以前，「/WebContentで固定」って書いたけど，ムリクリ直
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
■SQLServerのロック SQLServerでは「READ COMMITTED」がデフォルトの分離レベルとして設定されている。 上記説明通り「COMMIT済みのデータだけを読み取る」のだが、その読み取り方がREAD_COMMITTED_SNAPSHOT データベースオプション」の設定（ON,OFF）によって２種類の動作が可能になるというところがミソである。 この動作がOracleにはないのでちょっと戸惑うポイントだと思う。 ※READ_COMMITTED_SNAPSHOT オプションはデータベース オプション。 データベース単位で ON,OFF が可能。 ・READ_COMMITTED_SNAPSHOT オプションがOFFの場合 このオプションがOFFになっていた場合にデータ参照すると（Selectを発行すると） ☆共有ロックを取得する。 ☆参照が完了すると共有ロックを開放する。 とい
Ruby on Rails 7.1.3.2 Module ActiveRecord::Transactions::ClassMethods activerecord/lib/active_record/transactions.rb Active Record Transactions Transactions are protective blocks where SQL statements are only permanent if they can all succeed as one atomic action. The classic example is a transfer between two accounts where you can only have a deposit if the withdrawal succeeded and vice versa. Tr
DjangoからMySQLにCOMMITしたデータが別のトランザクションから見えない - orangain flavor
はじめに Djangoを使ったアプリケーションで、2つのバッチ処理用プロセスA、Bを同時に立ち上げたときに、Aのトランザクションでsave & commitした値をBでは読み取れないという問題に直面しました。 問題の箇所のソースコードはこのような感じです。 実行順 プロセスA プロセスB 1 with commit_on_success(): p = Post(id=1) p.save() 2 # saveしたデータが見える Post.objects.get(id=1) 3 with commit_on_success(): p = Post(id=2) p.save() 4 # saveしたデータが見えず例外発生 Post.objects.get(id=2) Djangoではデフォルトで自動コミットが有効なので、Aでコミットした値をBで読み取れるはずと思っていたのですが、これは間違いでし
はじめに 前回の「JavaからMySQLに接続して登録する」ではSQL文を１つ１つコミットしていましたが、今回は複数のSQL文の登録とトランザクション処理を紹介します。 トランザクション処理を行うと、複数のSQL文の内の１つ以上でエラーが発生した場合に、その全ての処理を無かった事にしてくれます。 テーブル こちらに登録します。 コード import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; import java.sql.SQLException; public class ConnectionClass { static final String URL = "jdbc:mysql://localhost/cm"; static final String U
この記事書いているあいだにこんなニュースを見つけた。これはすごいや。 100万PV／日のmixiモバイルアプリをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー さて、本題 不可能と思い込んでいたことができることもある 何度かイタい目に遭うことで、またどうせ出来ないだろうと思い込んでしまうことを学習性無力感という。長期間にわたって鎖に繋がれたままの犬は、鎖を外してもしばらくは逃げないそうである。GAEはもともと情報が少ないのと、嵌りどころ満載なこともあって、学習性無力感に陥ることがしばしばある。だから、一人悶々とやるより、Blogに晒したり、GAE Nightなどの集まりに出向くなどして、情報共有に努めるのがよろしいかと思う。そこで重要なのは、ありのままの事実を晒すということ。現時点で正しい答えを識っているものは皆無に等しいのだから、誰かに正しい答え
🙅♂️この記事の内容は実際のコードに適用しないでください！！ （2022-10-5追記） この記事の本文でトランザクションに joinable: false というオプションを付けることが推奨されていますが、 joinable: false は内部APIなので指定してはいけない、というのがRails開発チームの見解のようです。 https://github.com/rails/rails/issues/39912#issuecomment-665483779 https://github.com/rails/rails/issues/46182#issuecomment-1266550987 joinable: false を付けるとコミット実行前にafter_create_commitコールバックが呼ばれるなど（参考）、思いがけない別の問題を引き起こすことがあります。 というわけで、
テーマ 2003 年 2 月のオープンソースプロジェクトの開始以来、Spring Framework はますます強力になっています。ダウンロード件数は 100 万を超え、さまざまな業界のデファクトスタンダードとなり、エンタープライズ Java アプリケーションの開発に変化を与えました。 最も重要なことは、大規模かつ忠誠なユーザー基盤を築いたことです。このようなユーザーは Spring Frame の重要な価値を理解し、急速な進歩をもたらすフィードバックを与えてくれました。Spring には、常に以下のような明確な使命がありました。 非侵入的なプログラミングモデルの提供。できれば、アプリケーションのコードをフレームワークから切り離すべきである。 社内インフラに対する優れたソリューションを提供し、開発担当者が一般的な問題の解決ではなく、ビジネス価値の実現に注力できるようにする。 進展しつつある
この記事では、前回の記事PostgreSQLのrow-level lockの概要に引き続き、動きがわかりづらいPostgreSQLのrow-level lockについての解説を行います。 大まかな概要を掴むための記事なのですべての動作を網羅しているわけではないですし、一部解説に誤りが含まれていたり、正確ではない可能性があるのでご注意ください。 なお、クエリの実行例などはすべてPostgreSQL 13上での動作結果となります。 また、次の二つの拡張機能を利用しています。 https://www.postgresql.org/docs/current/pgrowlocks.html https://www.postgresql.org/docs/current/pageinspect.html ロックに利用される領域について row-level lockはタプルヘッダのt_infomask,
κeenです。最近KeenS/transaction-rs: The transaction abstraction library and its executors for rustというライブラリをリリースしたのでそれについて。 モチベーション Rustでドメインロジックを書いていると以下のようなコードが出てきました。 (実際はもうちょっと複雑ですが本質ではないので簡略化します) struct GroupPgDao(r2d2::Pool<ConnectionManager<PgConnection>>); impl GroupPgDao { fn get_conn(&self) -> &PgConnection { /*... */ } fn delete_user(&self, user: &User, group: &Group) -> Result<()> { let cn =
よく訓練されたアップル信者、都元です。2年越しの復活、Spring Frameworkの話題です。ベルセ◯クかっつーの。正直2年も経ってると思っていませんでした。感覚的には半年くらい…そんなわけないか。…まぁ、なんつーか適当にやってますんで、適当にお付き合いください（汗 さて前回は「次回はトランザクションです」なんていう終わり方をしたので、約束は果たすぞ。2年経ってても次回は次回だ。 トランザクション さて今回はトランザクションの話。あまり深いことを論じ始めると分厚い本が書けてしまう分野でもありますので、まず概略をお話し、そしてその中の一部に絞って話を進めます。 まず「トランザクション」という言葉については、WikipediaのトランザクションやACIDの項目をさらっと読んでおいてください。要するに、よくある例えが銀行振込処理で、「振込元の残高を減らす処理」と「振込先の残高を増やす処理」を
CAP定理というのは、 Consistency Availability Partitions という状態の2つまでしか達成できない。３つすべてを達成することはできないという定理である。例えばConsistency（一貫性）とAvailability(可用性)を同時に満足させるとPartitions(分散)を達成するのをあきらめるしかない。可用性と分散性を同時に満足させるにはConsistency（一貫性）をあきらめる。すなわちEventually Consistentな状態を受け入れる。 そーゆー状態を受け入れるとスケーラビリティを達成できるようになるので、巨大なデータセンターの中に安いPCサーバーを大量においてCAPのCを若干犠牲にしつつ、高速なデータ処理を行う。そのような計算モデルである。 クラウド時代の計算パラダイムがRDBMSが30年間研究開発していたACIDパラダイムからCAP
JBoss Advent Calendar 2011の14日目のエントリです。今日はJDBC XAデータソースの説明。 XAってなによ？ ツーフェーズコミット(2相コミット, 2PC)するためのインタフェースです。 XAとか2PCってどんなときに使うの？ 一つのトランザクションで2つ以上のトランザクショナルリソース(JDBC JCAリソースアダプタ=データベースとか、JMS JCAリソースアダプタとか)を扱う場合に利用します。 XAとか2PCってなんで必要なの？ 例えばデータベースが二つ、DB-AとDB-Bがあって、DB-AからDB-Bにデータを移す処理をするとします。このとき、DB-AからSELECTして削除してDB-Bにインサートする、というようなことをするわけですが、この処理が途中で落ちたら即データ消滅、データ重複などのデータ不整合という結果になってしまいます。XAを使うとこういった
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.10.3 InnoDB と TRANSACTION ISOLATION LEVEL
Section Navigation [Toggle] 13.5.10 InnoDB トランザクション モデルとロック13.5.10.1 InnoDB ロック モード 13.5.10.2 InnoDB と AUTOCOMMIT 13.5.10.3 InnoDB と TRANSACTION ISOLATION LEVEL 13.5.10.4 一貫非ロック読み取り 13.5.10.5 SELECT ... FOR UPDATE と SELECT ... LOCK IN SHARE MODE ロック読み取り 13.5.10.6 ネクスト キー ロック:バグの問題を防ぐ 13.5.10.7 InnoDB 内での一貫した読み取りの例 13.5.10.8 InnoDB 内で各種 SQL ステートメントによって設定されるロック 13.5.10.9 暗黙的なトランザクション コミットとロールバッ
預金の引き出しでは、残高確認→現金の引き出し→残高の更新という一連の処理を他のプロセサの処理からの干渉なく行う必要がある。 プロセサ1の引き出しの処理で、残高の更新を行う前に、他のプロセサが引き出し前の残高を読んで、引き出し、残高更新を行ってしまうと、処理がおかしくなってしまう。このため、Lockというメカニズムを使って、1つのプロセサがこの一連の処理を終わるまで、他のプロセサはこの処理を開始できないようにするというのが一般的なやり方である。しかし、これでは複数のプロセサがあっても一時には1つのプロセサしか使えず、効率が悪い。 プロセサ1が口座A、プロセサ2が口座Bの引き出し処理を並行に実行するのは問題ないので、口座ごとにLockを設ければこの問題は解決する。しかし、口座Aから口座Bへの振込をする場合は両方の口座のLockを獲得する必要がある。この時、プロセサ1が口座AからBへの振込のため
昨日の記事「メイヤー代数やメイヤー加群はまだ整理不足」において、 双代数の条件を入れておいたのはトランザクションのためでした。トランザクションは、「更新オペレータをローカルでキューイングする」方式を前提とします。 と書きました。 ここで、トランザクションについてザッと説明しておきます。下の絵のような3つの方式について紹介して、僕の立場からのコメントを付けます。それぞれの方式を切り離した絵も後に再掲します。 詳細はともかく、絵の見方は： 時間は上から下の方向に経過します。 Sは状態空間です。データベースの可能なすべての状態の集合と考えればいいでしょう。 Vは状態の観測値の集合です。観測値は状態に関する部分的な情報を提供します。 fは状態を変更する処理を行うプログラムです。 Mは状態を更新するオペレータの集まり、モノイドとなります。 黒三角はデータのコピー（クローン）です。 S→S×V という
SF作家のオーソン・スコット・カードがアニメ『カウボーイ・ビバップ』を絶賛しているという紹介記事があるのだが、どうもその訳が変だというので見てみたら想像を絶するひどさで驚いた。ここで紹介をしようと思ったが、そのひどさをいしがめさんが詳しく解説しているので、まずそれを見ていただこう。 http://d.hatena.ne.jp/ishigame/20110409/p1 理由がなんであれ、これはちょっとありえないレベルの酷さだ(最後の段落なんて、ほとんどこれは「訳者」の主張だろう)。そして、いくつかの元記事への反応で散見されるパート(「SF嫌いの妻」といった表現や菅野よう子の音楽を褒めている言葉)が原文に見当たらないか、ごく弱い表現だということもわかる。意訳というより、カードが言いたかったのはこういうことなのだろうという思い込みで混ぜ込まれた言葉が逆にバズを引き起こしているわけで、それはそれで
Posted by Nick Johnson | Filed under coding, app-engine, cookbook, tech This is the fourth in a series of 'cookbook' posts describing useful strategies and functionality for writing better App Engine applications. As promised, today we're going to discuss Distributed Transactions on App Engine. Distributed transactions are that feature that you didn't know you needed until they were gone: The abil
ファイルロック - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "ファイルロック" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2020年12月） ファイルロック（英: file lock）とは、コンピュータのファイルへのアクセスを一時的に1人のユーザーや1つのプロセスに制限する機構。このロックの目的はいわゆる「仲裁更新」(interceding update) のシナリオを防ぐことである。 概要[編集] 仲裁更新問題とは次のような例で表される。プロセスAおよびプロセスBがある顧客の口座残高を含むレコードをファイルから読み込み、各プロセスがその値を別々のメモリに保持している状況下で、次の事象が順番に発
トランザクション入門
トランザクション入門 2016 10/28 グランパーク田町 Tech Lunch @kumagi
基礎から理解するデータベースのしくみ（12）
両すくみで処理が停止することも ロック機能は複数のユーザーが利用するデータベース・アプリケーションには不可欠なのですが，新たな問題の元にもなります。それは「デッドロック」と呼ばれる現象です。 先の銀行口座間の振り込みの例で次のような場合を考えてください（図3[拡大表示]）。トランザクション1は，口座番号10の口座から口座番号20の口座に1万円を振り込もうとしています。一方，トランザクション2は，これとは逆に口座番号20の口座から口座番号10の口座に5000円を振り込みます。ここで仮に，トランザクション1が，(1)口座番号10のレコードを変更してから，トランザクション2が(2)口座番号20のレコードを変更したとしましょう。この時点で，トランザクション1は口座番号10のレコードを，トランザクション2は口座番号20のレコードを排他ロックします。これらのレコードは，トランザクションが終了するまでロ
2フェーズコミットと分散トランザクションの日本語のさっと読めるサイトなら、この辺よいですよと獄長に教わりましたｍ（＿ ＿）ｍ 5.X/Open の分散トランザクション処理参照モデル とかちゃんと知らなかったっす・・・・ http://www.ogis-ri.co.jp/otc/hiroba/technical/DTP/step2/index.html http://www.datadirect.co.jp/SupportLink/dev_center/jdbc/topics/jta （追記） 2フェーズコミットとその最適化として、あわせて読みたい 「2 フェーズコミットと Logging Last Resource，特許とオープンソース」 http://d.hatena.ne.jp/koichik/20081204#1228395633 ちょw、いま気づいたけど小林さんのblogが業務連絡
How Tarantool works Tarantool keeps all the data in random-access memory (RAM). Solutions of this class are fast, but they often lack data persistence. Tarantool helps overcome these problems. Try Tarantool to see how fast, flexible, and scalable it is. Download When to use in-memory? In-memory solutions are very fast because they work in RAM. This helps you avoid overhead associated with caching
HAKATA Test Night #1 で「トークンリフレッシュ処理を含むAPIClientのテスト」について喋ってきました #hakata_test_night - pixiv inside
おばんです、博多に行った際に一番美味しかったのは明太子だと思った田中です。「お前はまだ本当の博多グルメを知らない」的なマサカリ歓迎です。 さて、今回は先日博多で開催されたHAKATA Test Night #1で発表した内容についてまとめます。 HAKATA Test Night #1 - connpass 発表について トークンリフレッシュ処理を含むAPIClientのテスト #hakata_test_night from Kenji Tanaka 概要 Access/Refresh Token形式の通信処理は簡単にまとめると以下の手順を踏みます。 Access Tokenが有効期限切れだった場合に、Refresh Tokenを使ってAccess Tokenを更新する Refresh処理が成功したら、新しく取得したAccess Tokenを使って元の通信処理をRetryする これらの一連
TransactionalMemory - GCC Wiki
Transactional Memory in GCC Background Transactional memory is intended to make programming with threads simpler, in particular synchronizing access to data shared between several threads using transactions. As with databases, a transaction is a unit of work that either completes in its entirety or has no effect at all (i.e., transactions execute atomically). Further, transactions are isolated fro
ソーシャル旅行企画サービス？のtrippieceがリニューアルしたようですね。 MOVIDAからの出資も発表されたようです。概要などはTech Crunchの記事でご覧いただくとして、本稿ではテイストグラフやtrippieceのビジネスモデルに着目した記事をお届けします。 ■テイストグラフとは？ 一応、定義を振り返ってみましょう。「インタレストグラフ」と呼ばれることも多いですが「テイストグラフ」と同義であると捉えて差し支えないでしょう。 twitter/Facebook連動（によるログイン）をベースとして特定のカテゴリ（食/服/本など）に特化した情報をそのサイト内で共有していき、趣味が合う人同士で盛り上がることができるという、濃淡はあれどもコミュニティ要素のあるサービスです。 twitter/Facebook連動によりある程度の実名性が担保されることにより顔が見える相手とのコミュニケーショ
Bug for Install Linux on Atom Z8700 Portabook ポータブックのLinuxインストールバグ対策 2018 #東海道らぐNetwalker lab kapper
Railsのデータロック - Qiita
begin ActiveRecord::Base.transaction do . . raise 'ロールバックします' end p 'コミット' # トランザクション処理を確定 rescue => e p 'ロールバック' # トランザクション処理を戻す end transactionブロックの中で登録・更新処理を行う場合は、saveやupdateではなく、save!, update!を使用する。 transactionブロックの中で複数のモデルの更新を行った後に例外を発生させると、全部のモデルがロールバックする。 楽観的ロック 「競合は多分起きないだろう」という前提で、データの取得時には何もせず、更新時に競合をチェックする方法。 レコードのバージョン管理を行うため、テーブルにlock_versionカラムを追加する。その際、デフォルト値を0にする。 lock_versionはレコード
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Song of Cloud: 分散トランザクション処理の最適化
続ACIDからBASE - L'eclat des jours(2009-11-13)
MySQL InnoDBの行ロック - There's an echo in my head
appengine ja night #4 Transaction Puzzlers
やってる「見える化」@marsのメモ
SQLServer と Oracle の異なるロック思想: iTech Labo
ActiveRecord::Transactions::ClassMethods
JavaでMySQLのデータベースにトランザクション処理 | DevelopersIO
【Google App Engine】 Keyとカウンタは別々に考えるといいかも
【翻訳】ActiveRecordにおける、ネストしたトランザクションの落とし穴 - Qiita
Spring 2.0: 最新情報と Spring 2.0 が重要な理由
PostgreSQLのrow-level lockの動きについて - Qiita
Rustのトランザクション抽象化ライブラリ作った | κeenのHappy Hacκing Blog
第6回 Spring環境におけるトランザクション処理 | DevelopersIO
クラウドの一貫性って - noopな日々
JDBC XAデータソース - nekop's blog
Intelの次世代Core「Haswell」のトランザクションメモリを読み解く(前編)
トランザクションの3つの方式 - 檜山正幸のキマイラ飼育記 (はてなBlog)
オーソン・スコット・カードの「翻訳」記事がやばい件 @ val it: α → α = fun
Distributed Transactions on App Engine - Nick's Blog
2フェーズコミットと分散トランザクション - おおたに6号機blog
Tarantool Data Integration Platform
trippieceにみるテイストグラフ系サービスのマネタイズ手法 | The Startup
appengine ja night #6 図解Global Transaction