WR blog

今回のentryでは、「SECTION I Oracleアーキテクチャ概要」の「CHAPTER 02 クライアントアプリケーションとサーバープロセス」について補足説明します。 この章では、SQL*PlusなどのOracleに接続するアプリケーションである「クライアントアプリケーション」 とクライアントから指示に従い実際に処理を実行する「サーバープロセス」について説明しています。

あるクライアントアプリケーションがOracleに接続すると、そのクライアントアプリケー ション専用のサーバープロセスが起動します。 ここで、クライアントアプリケーションとサーバープロセスの間に設定されるコネクションを、 Oracleではセッションと呼びます。 これらについては、書籍で説明したとおりですが、このentryでは、 Linux上でクライアントアプリケーションとしてSQL*PlusでOracleに接続した場合を例に、 クライアントアプリケーションとサーバープロセスの関係について、 プロセスの相互関係、セッションの観点から確認してみます。

まず、SQLPlusを起動して、connectコマンドでOracleに接続すると、サーバープロセス が起動します。 これは、SQLPlusにおいて、fork()、exec()システムコールを実行することで、 プロセスが複製され、複製されたプロセスの実体がoracleプログラムに変わるためです。 このような処理を行うことで、サーバープロセスに対応したプロセスが新規に作成されます。 そして、このサーバープロセスはSQLPlusの子プロセスとなり、 サーバープロセスとSQLPlusは子プロセス、親プロセスの関係をもちます。 そして、2つのプロセス間にパイプと呼ばれるプロセス間通信路を設定します。 すなわち、セッションはパイプにより実現されるわけです。

ここで説明した動作を実際に確認してみましょう。 まず、SQL*Plusを実行して、Oracleに接続してみます。

[o11106@hp1 ~]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 日 11月 9 15:36:10 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

SQL> connect / as sysdba 接続されました。 SQL>

このとき、pstreeコマンドを使用して、プロセスの親子関係を確認してみます。

[o11106@hp1 ~]$ pstree -p -a o11106 bash(9438) (略) sshd,9667 `-bash,9668 [...]

November 9th, 2008 | Tags: Oracle, プロとしてのOracleアーキテクチャ入門 | Category: Oracle | Leave a comment

メインフレームとかは真面目に勉強しといたほうが良いかも

via 読書記録ChageLog

WOMeetingでのkawasakiさんのお話などを聴くと、 UNIX, Windows, IAアーキテクチャといった現状のIT基盤はイマイチ信用にかけると思わざるを得ない。IT基盤の究極の姿はメインフレーム的な機能・特性を持つものになるのかなと。

ちょっと勉強したい・・・が、どうやって？何のために？

ま、自身の技術的な興味はさておき、ユーザーのニーズにこたえるIT屋の立場にたって考えると、 キチンとしたIT基盤の上で仕事がしたい。とか思いませんか？

IT基盤がある程度の予見性をもった、信頼に足る基盤であるためには、メインフレーム的な基盤が必要であるように思える（素人なので話半分で・・・）。 とすると、いつかはメインフレーム的な基盤を使用することが一般的になるはず。 が、ここらへんの技術がコモディティ化してくるのは、一体いつになるんですかね・・・。 ユーザーがメインフレーム的な特性が実現できるよう、IT技術サプライヤに強く求めていくような構図ができないと、歩みはゆっくりにならざるを得ないでしょうね。

素人目で見ても仮想OSでは長い歴史のあるメインフレームOSの 仮想OS機能を知るのが第一歩だと思いますが。 もちろん一番気の毒なのは、UNIX系だけがOSだと思いこんでいる 人たちによるOSの授業や、研究指導を受ける学生さんたち。

うーん、メインフレームと大学って、なんで相性が悪いんでしょうか・・・ 確かに大学（某旧帝大）時代のコンピュータ系の研究室って2パターンに分かれていたような気がします。

*BSDマンセー プロセッサアーキテクチャ(?)

メインフレームはあまり扱ってなかったような気がします。なぜかUNIXが主流。 なんつーか、UNIXって一種のカウンターカルチャー的な部分を持つからそれが大学のカルチャーにマッチしたのかな？

August 6th, 2005 | Category: Infrastructure | Leave a comment

手持ちのトランザクション関連書籍をまとめてみる。なんとなく。

比較的わかりやすい。

難しい。

ほとんど読めてない。

OLTPシステム―オンライントランザクション処理

これまた難しい。

オススメできる。

追記@2005/06/03 ちょっぴり詳しいレビューはこちら

JTAに関連する箇所を拾い読みしただけ。

PoEAA 4th

次回開催までに、なんかしら読めたらいいな＆ネタ提供できたらイイなっと。

その他気になる点

DIコンテナ利用を前提にしたトランザクション処理 LL(PHP, Perl, … )な人のトランザクション処理 RDBMS分離性の使い分け

May 31st, 2005 | Category: Book, RDBMS | Leave a comment

from S2.2.9 リリース - koichikのひとりごと

例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合，最初に HSQLDB からコネクションを取得することで，二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます．

なるほどーそういうことか。理解できました！ ありがとうございます！ koichikさん。

昨日の質問

昨日のJ2EE勉強会(仮)で、以下の質問をさせていただいた。（若干、わかりやすく整理しています。昨日はもっと要領を得ない質問な感じ（苦笑）でした。）

S2JTAの枠組みの中で、XA非対応のリソースマネージャを扱う場合、XAをエミューレートするラッパ経由で扱うことになるようだが、その場合、

XA非対応のリソースマネージャ1つがJTA配下のトランザクションに参加している場合、1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ1つの場合、通常の1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ2つ以上の場合、2フェーズコミットプロトコルを使用する >

という理解でよいか？

なるほど、S2JTAの実装はLast Resource Commit Optimizationの機構を持っているため、 1番目、2番目の内容は正しいようだ。ただ、koichikさんの日記にかかれてあるように、

Last Resource Commit Optimization は，このように複数のリソースがある場合に，最後のリソースに対しては prepare ではなく，通常の 1 [...]

May 15th, 2005 | Category: Java, RDBMS, Seasar | Leave a comment