Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
GAE/Jを使うのに一番戸惑うのが、データのストレージがRDBMSではなく、Bigtableなことでしょう。 JOINが使えなかったり、WHERE句でORが使えなかったり、これまで慣れ親しんでいた方法が軒並み使えません。 これらの制限は、Bigtableに限ったことではなく、KVS(Key Value Store)型のクラウド系のデータベースではみんないえることだと思います。 最初、私も戸惑ったんだけど、いろいろ触っているうちに気付きました。昔、AS400でやってたころと一緒ジャンと。AS400とは、IBMから出ているオフコン(?)ですね。今は、System iと呼ばれているようです(最新だとまた違うようですが)。 AS400のファイル(テーブル)は、キーもしくはインデックスでアクセスします。インデックス(論理ファイル)は、ある行の特定のカラムがソートされていて、物理ファイル(テーブル)へ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
