データソース
これば、データを格納し、データをクライアントにストリーミングするためのインフラストラクチャです。これにより、ページのロードが高速になるとともに、結果の非同期サーバー処理が可能になります。基本的な方法としては、大きな結果セットがクライアントにチャンクで戻り、その ID を使用してさらにチャンクを取得できます。UI からは、データはクライアントにストリーミングされているように見えます。このアプローチは、データベース内に大きな結果セットが残る DB ページングとは異なります。DataSource では、データをチャンクでリクエストするクライアントをとるかぎりにおいて、結果はメモリに残ります。さらに、別個のスレッドでデータソースにチャンクを追加するサーバーがサポートされるので、クライアントが待機することなく、データソースをリクエストし、そのデータを取得するためのスレッドを提供することができます。
DataSource を使用すると次のような利点があります。
• クライアント側とサーバー側のリソースを過剰に消費することなくデータを表示できる。
• データのロード中にユーザーがページを操作できる。
• パフォーマンスが向上する。
• データのロード中にメッセージとフィードバックが提供される。
データソースのモード
同期: クライアントに送信する必要があるデータがすべて揃っていて、クライアントにチャンクで送信できるようにデータを DataSource に配置したい場合にこれは便利です。DataSource セッションは、クライアントに送信するオブジェクトのリストをとり、クライアントに送信されるデータの 1 つ目のチャンクが含まれている DataChunk オブジェクトを返します。データのリストが 1 つのチャンクに収まる場合、セッションは DataSource を作成せずに、チャンクだけを返します。そうでない場合、DataSource がデータとともに作成され、これに対して後から追加のチャンクをポーリングできます。データがさらに追加されないように、DataSource は閉じます。
非同期: この場合、データはまだ揃っていません。バックグラウンドスレッドでデータを取得して後からデータをクライアントに返すタスクをサブミットします。Java から提供されている Executor フレームワークの機能を利用します(詳細については、Executor の Javadoc を参照してください)。非同期 DataSource を作成するため、DataSource セッションは DataSourceTask をとり、これは後からバックグラウンドスレッドで実行されます。DataSourceFuture オブジェクトが返り、これによって DataSource 情報にアクセスできます。
無効: DataSource は無効になります。
データ取得での DataSource
同期データ取得での同期データソース: 同期データ取得を使用し (すべてのデータをデータベースから 1 つのチャンクで取得)、チャンクをクライアントにストリーミングします。空のチャンクは送信されないので、1 つ目のデータチャンクを受信するまでコンポーネントはレンダーされません。現在のところ、ツリーコンポーネントではこれはサポートされていません。
同期データ取得での非同期データソース: 同期データ取得を使用し (すべてのデータをデータベースから 1 つのチャンクで取得)、チャンクをクライアントにストリーミングします。クライアントに送信される最初のデータチャンクはテーブルデータを含みませんが、このチャンクによって、完全なデータチャンクが利用可能になる前にテーブルがレンダリング可能になります。間もなく、テーブルおよびテーブルの処理の一部をユーザーが制御できるようになります。次に、データチャンクは処理済みなので、空のチャンクにデータチャンクが入ります。
非同期データ取得での非同期データソース: 非同期データ取得を使用し (データをデータベースから複数のチャンクで取得)、チャンクをクライアントにストリーミングします。クライアントに送信される最初のデータチャンクはテーブルデータを含みませんが、このチャンクによって、完全なデータチャンクが利用可能になる前にテーブルがレンダリング可能になります。間もなく、テーブルおよびテーブルの処理の一部をユーザーが制御できるようになります。次に、データチャンクは処理済みなので、空のチャンクにデータチャンクが入ります。この場合、データベースからデータを取得中に、クライアントでデータのチャンクをレンダーできます。
ツリーの場合にはロードの動作が異なります。Windchill 9.x では、深さ優先のロードアプローチをとっており、各ノードがそのリーフノードまで展開されてから、兄弟ノードが展開されました。Windchill 10 では、DataSource を使用し、幅優先のロードアプローチに移行しました。ノードはレベルごとにロードされます。
データソースの監視
DataSourceMonitor MBean を使用して、各種プロパティを監視および設定できます。モニターを検出するには
• windchill シェルから、"jconsole" を実行します。
• MethodServerMain を選択します。
• 「MBeans」タブを選択します。
• MBean は com.ptc>WebAppContexts>${WEBAPP_NAME}>Monitors>DataSourceMonitor にあります。
MBean の監視
パラメータ | 説明 |
|---|---|
ActiveDataSourceCount | すべてのユーザーセッションで現在アクティブなデータソースの数。 |
TotalDataSourcesCreated | すべてのユーザーセッションで作成された DataSource の総数。 |
TotalDataSourcesDestroyed | すべてのユーザーセッションで破棄された DataSource の総数。 |
MBean オペレーション
パラメータ | 説明 |
|---|---|
cancelLongRunningDataSources | すべてのユーザーセッションで、指定されたミリ秒以上実行しているデータソースをすべてキャンセルします。アクティブな DataSource と非アクティブな DataSource の両方がキャンセルされます。 |
MBean コンフィギュレーション
パラメータ | 説明 |
|---|---|
AllEmptyPollingTimeout | クライアントがチャンクの有無をポーリングし、リクエストした ID のいずれにも使用可能なチャンクがない場合に、データチャンクを待機するときのタイムアウト (単位: ミリ秒)。 |
ChunkBlockingLimit | DataSource に格納可能なチャンクの数を制御します。この数を超えると、ポーリングされるかタイムアウトになるまで、アイテムを追加できなくなります。これによって設定される実際のアイテム数は ChunkBlockingLimit*MaxChunkSize です。 |
DataSourceTaskPoolKeepAliveTime | アイドルスレッドを DataSource タスクプールに残す時間 (単位: ミリ秒)。 |
DataSourceTaskPoolSize | DataSource タスクプールに置くことが可能なスレッドの最大数。 |
DataSourceTimeout | アイドル DataSource を残す時間 (単位: ミリ秒)。 |
FeedbackBlockingLimit | DataSource に格納可能なフィードバックアイテムの数。この数を超えると、ポーリングされるかタイムアウトになるまで、フィードバックを追加できなくなります。 |
InitialChunkPollingTimeout | 非同期データソースを使用している場合に、使用可能なデータの最初のチャンクを待機する時間 (単位: ミリ秒)。これにより、可能な場合、コンポーネントは最初のレンダリングでテーブル内の一部のデータの表示を試みます。 |
MaxPollSize | 各ポーリングで DataSource から返るデータの最大サイズ。 |
PreferredMinPollSize | ポーリングでのデータの最小サイズ。非同期データソースをポーリングする場合に、サーバーはこれに基づいて、さらなるデータを待機するかどうかを決定します。 |
PreferredSerializationSize | ポーリングリクエストに対する総レスポンスの推奨サイズ (単位: バイト)。最初のチャンクがこのサイズの上限に達していない場合、上限を超えるまで、チャンクが追加されます。このプロパティは、現在使用されていません。 |
ResultLimit | DataSource に追加可能なアイテムの総数。この数を超えると DataSource が失敗します。 |
SomeEmptyPollingTimeout | クライアントがチャンクの有無をポーリングし、リクエストした ID のすべてではなく一部に使用可能なチャンクがある場合に、データチャンクを待機するときのタイムアウト (単位: ミリ秒)。 |
TreeChildNodeFetchTimeout | ツリーの子データを待機するときのタイムアウト (単位: ミリ秒)。既成の値は 180000 ms で、この値を大きくすることによってタイムアウトエラーを回避できます。 |
更新された MBean コンフィギュレーションの値を残す
"DataSourceMonotor" MBean の更新されたコンフィギュレーションの値を XML に残すことができます。
• Jconsole を開き、"DataSourceMonitor" MBean のコンフィギュレーション可能な値を変更します。
• "DataSourceMonitor" MBean をクリックします。MBeanInfo から、"ObjectName" をコピーします。
• Loader MBean com.ptc > WebAppContexts >${WEBAPP_NAME} を開きます。
• その「Operation invocation」タブを開きます。
• "addInjectionTargetMBean" メソッドのパラメータとして "ObjectName" を貼り付けて、「addInjectionTargetMBean」ボタンをクリックします。
• 次に、「Save」ボタンをクリックします。"DataSourceMonitor" MBean の変更された値が <WT_ホーム>/codebase/WEB-INF/wtWebAppMBeans.xml ファイルに残ります。後からサーバーを再起動すると、最後に保存された値が "DataSourceMonitor" MBean に表示されます。
• コンフィギュレーション可能プロパティをデフォルト値に戻すことができます。これには、"ObjectName" を指定して "removeInjectionTargetMBean" を呼び出した後、"保存" 操作を実行します。
パフォーマンスに関する問題
• コンポーネント当りのスレッド数
さまざまなサイズとタイムアウトを調整する MBean プロパティに加え、プロパティ numberOfThreadsPerComponent はコンポーネント全体のパフォーマンスに影響を与える可能性があります。このプロパティは、データユーティリティを介してデータベースのデータを処理する際にコンポーネントに許可される最大スレッド数を修正するときに使用します。これらのスレッドは RawDataChunkSize MBean 値のサイズのデータを処理し、一時的です。データベースからのデータはスレッドを増やす必要が生じるほどの速さにはならないので、この数を大きくしてもこれ以上の役には立ちません。ほとんどの場合、同時に実行するスレッドの最大数は 2 になります。以下に示す例では、このプロパティにデフォルト値が示されています。com.ptc.core.components.factory.dataUtilities.numberOfThreadsPerComponent=3
• WAN クライアントと MaxPollSize
WAN クライアントの場合、maxPollSize 属性には大きい数値を設定すると動作が少し改善されることがあります。LAN クライアントの場合、リクエストを行う際の待ち時間のペナルティが小さいので、小さい値の方が高速になります。500 は両方のシナリオで適切に機能するバランスのとれた値です。クライアントのブラウザは複数の Ajax リクエストを使用してデータをダウンロードする必要があります。同時リクエストの数は 3 つに制限されています。これは、データをこれ以上の速度では取得できないので、これを上回るリクエストを行ってもダウンロード速度が向上しないためです。この時点ではこのプロパティは設定できません (PTC.jca.DataSourceRegistry.MAX_REQUESTS)。