Song of Cloud: グローバルトランザクション処理のパターン
送金のトランザクション処理パターンでは、Google App Engine (GAE)のEntity Groupにまたがるトランザクション処理を行う方法について紹介しました。また、それに少しだけ最適化を施した結果、下図のような処理になりました。 しかし、このトランザクション処理はいくつかの制約があります。 (a) 送金中に合計金額がずれる (b) 送金先の口座に制約をかけられない このトランザクションはEventual Consistency (結果整合性)というレベルの整合性保証しかしないため、2つのEntity Groupの値にずれが発生する場合があります(a)。たとえば、口座(A)から口座(B)に1000円だけ送金する場合、(1)と(2)の間は「口座(A)から出金したが、口座(B)に入金されていない」という状態になります。 また、送金元の口座に制約はかけられますが、送金先の口座に制約
Song of Cloud: グルージェントWebページの裏側 (2)
弊社WebサイトはGoogle Bloggerと統合し、bloggerへの記事がマスターデータとしてGAEのデータストアにレプリケーションしています。弊社サイトのメインメニューとフッターメニューは管理画面で編集ができるようになっていますし、GWTのコンポーネントとして独立できるように実装しているのですが、残念ながらbloggerに使うことができていませんでした。 クロスサイトスクリプティングになっちゃうよ問題 弊社サイトが www.gluegent.com、Bloggerが songofcloud.gluegent.com となっているため、Webブラウザのクロスサイトスクリプテイングのセキュリティ制限により、GWT側からblogger側のURLを操作することができなかったのです。 それではと、GAEのモジュールを展開してblogger側に配備することを試してみました。しかしGAEのビルド
Song of Cloud: 認証あれこれ
GAEの認証 GAEのアプリケーションを開発するに当たって、まず最初にどのような認証機能が必要かをあらかじめ整理しておくべきです。提供されている認証機能を把握することが先決で、独自の認証機能を開発するというのは最後の手段にすべきです。認証情報をGAEに任せることでユーザーのパスワードがアプリケーションから漏洩するというリスクを背負う必要がなくなります。ただしGAEの認証情報（UserAccount API）には、アカウントID、ログイン状態、GAE管理者か否かの３つの情報がアプリケーションから把握できるに過ぎません。もしアプリケーションで何らかの付属情報を持たせたい場合にはデータストアを使う必要があるでしょう。 GAEではデプロイするアプリケーションIDの発行の際に認証方式を選択する必要があります。後からこれを修正することができません。選択する認証方式とは、一般のGoogleアカウントを使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
