タグ

transactionに関するairj12のブックマーク (11)

  • Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)

    といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいいだと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という2つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく

    airj12
    airj12 2015/05/08
    こういう事に頭を悩ませる開発がしたい
  • 分散トランザクションの概念

    32 分散トランザクションの概念 分散トランザクションの概要とその整合性を維持するOracle Databaseの仕組みについて説明します。この章の内容は、次のとおりです。 分散トランザクションの概要 分散トランザクションのセッション・ツリー 2フェーズ・コミット・メカニズム インダウト・トランザクション 分散トランザクション処理: 事例 分散トランザクションの概要 分散トランザクションは1つ以上の文からなり、それらが個別に、またはグループとして、分散データベースの複数ノードのデータを更新します。たとえば、図32-1に示すデータベース構成を考えます。 図 32-1    分散システム 画像の説明 scottによって実行される次の分散トランザクションは、ローカルのsalesデータベース、リモートのhqデータベース、およびリモートのmaintデータベースを更新します。 UPDATE scott

  • Replicated Serializable Snapshot Isolation解説 - 急がば回れ、選ぶなら近道

    ちょっと諸般の事情で放りだしてあったのですが、まとめておかないと忘れるので、記録的においておきます。あとでたぶん自分でも見直すと思うので。 このエントリーは完全にトランザクションの人向けです。現時点これが当に必要な人は世界でたぶん50人ぐらいだと思います。全日的には絶対わかんないとまずいという人はたぶん5人ぐらいです。 ただし、分散DBガチの人はわかっていた方がいいと思うので、おいておきます。 論文はこちら http://sydney.edu.au/engineering/it/~hyungsoo/vldb2011.pdf 内容はSerializable Snapshot Isolation (以下SSIと略記)の分散環境下への適用に関する論文です。一応実装もあってベンチマーク結果が出ています。SSIについては下記エントリーを参照にしてください。 http://d.hatena.ne.

    Replicated Serializable Snapshot Isolation解説 - 急がば回れ、選ぶなら近道
    airj12
    airj12 2013/08/19
    Oh…わかる気がしない
  • TX本勉強会終了 - 急がば回れ、選ぶなら近道

    先日をもって無事に読了しました。記念に記録しておきます。 読んだはこれ Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery http://www.amazon.co.jp/Transactional-Information-Systems-Algorithms-Concurrency/dp/1558605088/ref=sr_1_1?ie=UTF8&qid=1370746124&sr=8-1&keywords=transactional+information+systems 始まったのが、2011年の秋からだったので、ほぼ一年半かかりました。スタート時点は10名ほどいたメンバーも徐々にいなくなり、最後は不動の4人のレギュラー

    TX本勉強会終了 - 急がば回れ、選ぶなら近道
  • 全IT関係者が知っておくべき「1-copy-snapshot isolation」 - 急がば回れ、選ぶなら近道

    snapshot isolationを分散環境に適用する場合の「基」の内容のまとめになります。(基自分用のメモなので、間違っていたらすみません) まずワーディングの整理 ・snapshot isolation TXの分離レベルとしてのsnapshot isolation(以下SI)は、現在のRDBMSのTX管理では、ほぼ実装的にはデファクトと見ていいと思います。ただしANSIの規定のISOLATION_LEVELには定義がないので、どのあたりに位置づけるのかは、DB実装のそれぞれの取り扱いにより異なります。とはいえ、どのDBでもほぼSERIALIZABLEに近い位置づけにしているところが多いですね、というか、SI(特にSerializable SI)ぐらいでないとserializableに現実的には近づけないというのが実態かと思います。(勿論理論上はS2PLで実装は可能ですが、まぁパフ

    全IT関係者が知っておくべき「1-copy-snapshot isolation」 - 急がば回れ、選ぶなら近道
  • クラウドを支える基盤技術の最新動向と今後の方向性

    2. 目的 • クラウドの分散システムや大規模データベー ス技術の発展の歴史、現在の動向、将来の方 向性 – CAP 定理の制約をどのように克服しているか – 可用性技術がどのように保証されているか – OLTP が分散システムでどう拡張されたか – 開発手法として考えていくべき課題と対応は何か – Big Data の次の基盤の重要な要素技術は何か (C) 2012 Microsoft Corporation 2 3. Agenda • 分散システムとは – CAP 定理 • 可用性を支える複製 – P-B – ROWA – quorum – RSM、Paxos – A/E 分離 • スケーラビリティ OLTP プロトコルの発展 – Group safety – 2PC に代わる atomic broadcast – View synchronous • 設計論 – 次世代アーキテクチャ

    クラウドを支える基盤技術の最新動向と今後の方向性
  • Making Snapshot Isolation Serializable 再考 - 急がば回れ、選ぶなら近道

    Making Snapshot Isolation Serializable 再考 ■2013年的な位置付け まずちょうど年度の開始なので、今年は自分的にはRDBMS関連の位置付けとか整理しておきます。去年の後半あたりからの匂いですが、NoSQL的な発展と合わせて、格的なDB回帰が始まっている感じです。NoSQL系のほぼ致命的な弱点の一つがtransaction処理であることは指摘も多いところです。要するにデータが書き込めても不整合が発生しますね、ということになってしまいます。これではなかなか使えない、というのが現状でしょう。 なので、RDBMの最良のノウハウであるtransaction処理とNoSQL的な分散処理をちゃんと整合性とれるようにしましょう、という自然な流れは従前よりもより強い要請が働くでしょう。(できるかどうかは別ですが。) それで、そろそろなんかその手のものがRDBMS

    Making Snapshot Isolation Serializable 再考 - 急がば回れ、選ぶなら近道
    airj12
    airj12 2013/04/01
    途中からわかんなくなった…
  • クラウドを支える基盤技術の最新動向と今後の方向性

    知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月 VirtualTech Japan Inc.

    クラウドを支える基盤技術の最新動向と今後の方向性
  • A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道

    元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。(尚、当然ですが、内容が正確かどうかは

    A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
  • Intelの次世代Core「Haswell」のトランザクションメモリを読み解く(前編)

    預金の引き出しでは、残高確認→現金の引き出し→残高の更新という一連の処理を他のプロセサの処理からの干渉なく行う必要がある。 プロセサ1の引き出しの処理で、残高の更新を行う前に、他のプロセサが引き出し前の残高を読んで、引き出し、残高更新を行ってしまうと、処理がおかしくなってしまう。このため、Lockというメカニズムを使って、1つのプロセサがこの一連の処理を終わるまで、他のプロセサはこの処理を開始できないようにするというのが一般的なやり方である。しかし、これでは複数のプロセサがあっても一時には1つのプロセサしか使えず、効率が悪い。 プロセサ1が口座A、プロセサ2が口座Bの引き出し処理を並行に実行するのは問題ないので、口座ごとにLockを設ければこの問題は解決する。しかし、口座Aから口座Bへの振込をする場合は両方の口座のLockを獲得する必要がある。この時、プロセサ1が口座AからBへの振込のため

    Intelの次世代Core「Haswell」のトランザクションメモリを読み解く(前編)
  • Welcome back to the TRANSACTION! - 急がば回れ、選ぶなら近道

    最近、トランザクションの再勉強を始めていて、先日クラウド温泉でも発表させてもらった手前、ちょうどいいので一回まとめておく。はじめに断っておくと自分は別にDBやTXの専門家ではない。なので以下の内容の正確性については保証しない。内容については自分で勉強してくださいね。 1.「なんでまたTXなのか」 まずもって何故にTXなのか?というお話から始めます。もう枯れてんじゃないか?今頃RDBMSでもないだろう。それはそうですが、以下の流れは無視できません。 ・RDBMSの特許切れ NIIの佐藤先生の指摘にもあるように、1980-90年代のRDBMS関連の特許が切れ始めます。これにより商用一辺倒で、OSSではどうしても勝てなかったRDBMSでの技術革新や、その技術を応用した別のもの(RDBMSとは限りません)が登場してくる可能性が高いです。各ベンダーもそれを見越して、一斉にRDBMS関連への「逆張り」

    Welcome back to the TRANSACTION! - 急がば回れ、選ぶなら近道
  • 1
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy