Java EE7 と JCache 	  @maruyama097  丸山不二夫
はじめに	o  筆者の基本的な問題意識は、ネットワーク上のマーケッ    トが急速に拡大するという展望の中で、エンタープライズ    ・システムを、もっと高速でスケーラブルなものにしつつ、    トランザクションの正確性をきちんと担保すること...
はじめに	o  プレゼンの前半で、同じキャッシュというくくりで、CPUと    メモリーの間に置かれている、キャッシュの問題について    Cliff Clickの議論の紹介をした。もっとも、これは、キャ    ッシュが有効に機能していないと...
Agenda	o  CPUとキャッシュo  Multi-Core CPUとメモリーo  システムの階層性とキャッシュo  WebアプリのScale-outと    分散メモリーキャッシュ、NoSQLo  JSR 347: Data G...
CPUとキャッシュ	  Not Your Fathers Von Neumann  Machine:A Crash Course in Modern  Hardware  Cliff Click Azul Systems  Brian Goet...
CPU Performance	                              Multicore era	               Frequency scaling era 	  CISC era
CPUとメモリーのスピードのギャップ	o  CPUとメモリーのスピードのギャップは拡大している。か    つてのCPUのメモリーアクセスは、レジスターのフェッチ    よりほんの少し遅いだけだった。今日では、メイン・メ    モリーからのデー...
CPUのキャッシュ	o  かつては、乗算は高価な処理で、メモリーからのLoad    は安価な処理だった。しかし、今では、乗算は安価な処    理で、メモリーからのLoadは、高価な処理である。	o  CPUとメモリーのスピードのギャップが...
コードとデータの局所性	o  キャッシュが効くのは、多くのプログラムのコードもデー    タも「局所性」を持つから。コードとデータは、それぞれ    固有の「局所性」を持つので、コードのキャッシュとデー    タのキャッシュの両方が必要である。
データをCPUの近くに置く	o  「データをCPUの近くに置くこと!」 メモリー遅延の最    大の要因は、伝送線の遅延である。ここでは、情報伝    達の上限である光のスピードが問題になる。1GHzの    CPUの1クロックの間に、信号は...
メモリーは、新しいディスク	o  キャッシュミスの確率は、現在ではかなり低い。ただ    、キャッシュミスによって、100〜1000命令分の時間の    コストが発生する。だから、キャッシュミスの確率が5%    前後だとしても、パフォーマン...
Multi-coreとキャッシュ	o  Multi-coreのシステムでは、最下層のキャッシュは、い    くつかのコアで共有されている。o  しかし、全てのキャッシュが、全てのコアから見える訳で    はない。
Multi-Core CPUとメモリー
http://www.socip.org/socip/speech/pdf/20110708-080436-Perfectvips-SoCIP%202011%20Presentation.pdf	わずか10年の間のトランジスタ数の変化
Multi-Coreのコア数とトランジスター数	 コア数	       トランジスター数	        CPU	       2	          300M	       Apple A5	      10	         2600M	 ...
Multi-Coreのコア数と外部メモリー	o  コアの数が増えても、そのチップからアクセス可能なメモリ    ーの量は、コアの数に比例して増えていく訳ではない。‎10    0コアのTilera TileGX100が、10コアのWestMe...
SCCのメモリー構造	                                共有外部メモリー(可変長)	コア毎の       L2       L1                   コア毎の       L2       L1外部...
SCCの共有仮想メモリー空間	o  コアをまたいだ、共    有仮想空間が利用        アプリケーション	    できる。o  アプリケーションか          共有                     仮想メモリー	    ...
SCCの物理アドレス	o  SCCのそれぞれのコアは、32ビット(4GB)のア    ドレス空間を持っている。o  通常は、物理アドレスは、FSB(Front Side    Bus)上に見える。o  SCCでは、物理アドレスは、十分では...
48コアが、4つのメモリーコントローラを持つ。デフォールトでは12コアに一つのコントローラが割り当てられている。
In-Memory CommunicationMechanisms for Many-Cores -Experiences with the Inte SCC	    http://communities.intel.com/docs/DOC-...
Efficient Memory Copy Operations onthe 48-core Intel SCC Processor	       http://dare.uva.nl/document/356252
システムの階層性とキャッシュ
処理スピードで規定される階層性	o  システムの階層性を規定しているのは、処理のスピード    である。次のような階層がある。     CPU > メモリー > ディスク > ネットワークo  キャッシュは、基本的には、階層間をつなぐ働きを...
メモリーのコストの階層性	o  処理スピードの階層性の他に、コストの階層性がある。    基本的には、処理スピードの階層性を裏打ちしているよ    うにも見えるが、本来は、別の原理である。 SRAM > DRAM > SSD > Disko...
ネットワークのスピードとコスト	o  こうした処理スピードとコストの階層性は、固定的なもの    では無い。ネットワークの処理スピードは向上し、コスト    は低下しうる。もし、次のようになったら?  CPU = ネットワーク > メモリー ...
ディスクの価格低下のインパクト	Hard Disk	                          半導体のMoore則	                           ディスクの価格低下	          ディスク1G 5円   ...
ACM 2012The Future of Microprocessors	o  プロセッサのパフォーマンスの新しい基本的な制限が、    エネルギー効率だと言う視点からの分析。o  今日のプロセッサのパフォーマンスは、毎秒100Giga-...
o  もしもオペランドが平均して1mm (ダイサイズの10%)    移動するとして、0.1pJ/bitの割合だとすると、576T-bit    sの移動は、約58ワットを消費することになり、計算に    必要なエネルギーは、ほとんど残ってい...
WebアプリのScale-outと分散メモリーキャッシュ、NoSQL
Web Appli Multi-tier のScale-out戦略	                                         Daa Base	          Web Server  Business Logic
Web Appli Multi-tier のScale-out戦略	                      Web Server Business Logic	    Load Balancer	                      ...
Web Appli Multi-tier のBottle Neck	                      Web Server Business Logic	    Load Balancer	                      ...
Multi-tier の分散メモリーCache	                  Web Server Business Logic	Load Balancer	                                        ...
Cloud上の分散データベース	      On Memory   Persistency	         Hash
分散キャッシュのプロダクト	o  市場には、多くの分散キャッシュのプロダクトが、存在し    ている。o  代表的なものをあげれば、    OracleのCoherence (Cameron Purdy)、    IBMのeXtreme S...
キャッシュとNoSQLの比較	o  キャッシュは、Key/Value。    NoSQLのあるものは、Key/Value。o  キャッシュの主目的は、パフォーマンス。    NoSQLの主目的は、永続性。o  キャッシュは、永続性を持ちう...
キャッシュとNoSQLの比較	o  キャッシュのサイズは小さい。〜数十GB    NoSQLのサイズは、数TB〜数PBo  キャッシュはメモリーに置かれる。    NoSQL、RDBMSは、ディスクに置かれる。o  キャッシュは、メモリー...
JSR 347: Data Grids for theJavaTM Platform
Description	o  この仕様は、分散データグリッドに、アクセスし、格納し    、データを管理するAPIを提供することを目的としたもの    である。o  最初のAPIは、JSR-107 (JCACHE) APIの上に、そ    ...
o  JSR-107の上にそれを超えて、このJSRは、権限の引    き渡し、複製化、分散、トランザクション(JTAの仕様に    基づいて)の特徴と期待される特質を定義するだろう。o  さらに、非同期で、ノンブロッキングなAPIを、JSR...
o  この仕様は、まだ完成していないJSR-107の上に構築    される。我々は、彼らのスケジュールが、このJSRのス    ケジュールと両立出来ることを保証する為に、JSR-107    のEGと、ともに作業する意向である。もし、JSR-...
Proposed features	o  Async API (Future based)	 public interface AsyncCache<K, V> {       Future<V> get(K key);       Futu...
Proposed featureso  Distributed code execution  n  Map/Reduce  n  Alternate proposalo  Group APIo  CDI (Contexts and ...
Proposed features	o  Configurationo  Drop-In Replacement for JSR-107    Compliant Caches
JSR-347 Spec LeadManik Surtani氏とのインタビュー	o  JSR 347はJavaプラットフォーム向けのデータグリッド    としても知られていますが、APIとプログラミングモデル    、そしてフォルトトレラント...
JSR-347 Spec LeadManik Surtani氏とのインタビュー	o  分散。JSR 107の実装は分散化されていてもかまいま    せん。一方、JSR 347の実装は分散化されていなけれ    ばなりません。従って、JSR 3...
JSR-347 Spec LeadManik Surtani氏とのインタビュー	o  Map/Reduceと分散コード実行。データがグリッド上に分    散/パーティションされている場合、コードの実行をデー    タ側に移動させた方が他の方法...
JSR-347に対するVMWareの反対意見	o  VMware has serious concerns around the    proposed JSRs relationship with JSR-107.    While we ...
JSR-347に対するVMWareの反対意見	o  We do believe that this area is important and    warrants interest from the JCP. The JSR-347   ...
Object Caching for Java	   Functional Specification for Object   Caching Service for Java (OCS4J), 2.0   http://jcp.org/ab...
Objectの三つのタイプ	1.  決して変化しないオブジェクト n  staticで初期化すればいい2.  ユニークで使い捨てのオブジェクト n  使うたびにnewすればいい3.  上記2つの中間のオブジェクト n  Javaは、先2つ...
Object Caching Service for Java(OCS4J) の目的	o  Caching Service for Java (OCS4J)の目    的は、アプリケーションが、リクエストやユーザ    ーやプロセスをまたいで...
キャッシュされたオブジェクトのLife Cycle	o  オブジェクトの生成 n  ユーザーが定義したLoaderで行われる n  不要な生成を避ける為に、キャッシュシステムと     の協調が必要o  オブジェクトの無効化 n  ア...
キャッシュされたオブジェクトのLife Cycle	o  オブジェクトの削除 n  最近使われていないオブジェクト n  削除されたオブジェクトは、ディスクにスプール可能 n  スプールの決定は、ユーザーが定義したオブジェク     ト...
キャッシュとプロセス	o  システムの単純性、可用性、パフォーマンスの    為に、オブジェクト・キャッシュは、それぞれのプ    ロセスに結びつけられている。o  キャッシュ・システムでのオブジェクトの生成    には、中央からのコントロ...
GAEでのJCache の利用
Cache インスタンスの取得	Cache cache;     try {         CacheFactory cacheFactory =              CacheManager.getInstance().getCach...
値の設定と取得	String key;        // ...	        byte[] value; // ...      // Put the value into the cache.      cache.put(key, v...
有効期限の設定	 Cache cache; Map props = new HashMap(); props.put(GCacheFactory.EXPIRATION_DELTA, 3600); try {     CacheFactory c...
値の有効期限は次のプロパティで制御	o  GCacheFactory.EXPIRATION_DELTA: 値を設定    した時点から有効期限までを秒数で指定する整数値	o  GCacheFactory.EXPIRATION_DELTA_M...
設定ポリシーの設定	Map props = new HashMap();props.put(MemcacheService.SetPolicy.ADD_ONLY_IF_NOT_PRESENT,true);
o  MemcacheService.SetPolicy.SET_ALWAYS: キ    ーに値が存在しない場合は値を追加し、そのキーの値    が存在する場合は既存の値を置き換えます。これが    デフォルトの設定です。	o  Memc...
キャッシュの統計	 CacheStatistics stats = cache.getCacheStatistics(); int hits = stats.getCacheHits(); int misses = stats.getCache...
サポートされていない JCache 機能	o  JCache Listener API は、onPut リスナや    onRemove リスナなど、アプリケーションの API 呼び    出しの処理中に実行できるリスナについては一部サポ  ...
o  非同期のキャッシュ読み込みはサポートされていません。   	o  put() メソッドは、キーの以前の値を認識していても値    を返さず、常に null を返します。
JSR107 JCache 仕様	  「一時的なメモリー内のJavaオブジェクト  のキャッシングのAPIとセマンティックスを規  定する。オブジェクトの生成、共有アクセス、  スプーリング、無効化、複数のJVMをまたい  だ整合性を含む。」
経緯	o  2001年5月 JSRスタートo  2003年12月 CoherenceのCameron Purdy、    Spec Leadにo  2007年5月 EhCacheのGreg Luck、co-Spec    Leadにo ...
現時点でのRIに 含まれているパッケージ	o    javax.cacheo    javax.cache.annotationo    javax.cache.evento    javax.cache.mbeanso    jav...
Chapter 1 - Introduction
目的	o  キャッシングは、アプリを劇的にスピードアップする、試    されずみの、真実の方法である。o  アプリは、生成するのに高価だが再利用可能なライフタ    イムを持つ一時的なデータを、しばしば、使うことがある。o  例えば、サー...
o  この仕様は、Javaオブジェクトのキャッシングの標準化    を行い、その効果的な実装を可能とし、キャッシュのエ    クスパイア、相互排他制御、スプーリング、キャッシュの    整合性といったものを実装する重荷を、プログラマーか   ...
目標	o  Object Cache:    このAPIは、Javaオブジェクトをキャッシュする。o  Support for By-Value caching and    optionally, By-Reference.    後者の...
o  Java SE  この仕様はJava SEのもとで機能する。o  Java EE    この仕様は、Java EEのもとで機能する。この仕様は、    Java EE7に含まれることを目標としている。o  Annotations  ...
Chapter 2 - Caches
キャッシュとは?	o  キャッシュは、一時的なデータを格納する場所    である。それは、Mapに似たAPIを提供する。    Mapと同様に、データはキーの値として格納さ    れる。o  データは、Mapと同じく、ユニークな識別子であ ...
キャッシュの利用	o  データベースからのデータがキャッシュされると    よく思われている。もし、JPAを使っているなら、    確かに、そういうことになる。o  ただ、基本的には、作り出すのが高価で時間を    要するものは、なんであれ...
キャッシュの利用例	o  データベースの行のキャッシングo  プロセス中のNoSQLデータのキャッシングo  サーブレットのレスポンスのキャッシングo  クライアント側でのWebサービス呼び出しのキャ    ッシングo  イメージのレ...
キャッシュのKey/Value	o  KeyとValueに、特別の型の制限はない。o  ただし、KeyとValueは、Nullであってはなら    ない。nullキーでのアクセスも、null valueを    設定しようとした場合にも、 ...
o  キャッシュは、 storeByValueをサポートしなければ    ならない。その意味は、キー/バリューを、オブジェクトで    はない表現に変換する方法がなければいけないという    ことである。 これは、典型的には、ネットワーク上で...
キャッシュを見つける	o  CacheManagerは、キャッシュを管理する。o  キャッシュは、名前で同定され、アクセスされる。o  キャッシュへの参照は、次のようにgetCache    で得られる。Cache cache = cac...
Chapter 3 - Cache Operations
Cache Operations	o  Cacheインターフェースは、 ConcurrentMap    パターンに基づいている。ただ、それを継承した    ものではない。o  というのも、 ConcurrentMap (とMap)のメソ ...
Cache メソッド	o  V get(K key)               o  void putAll(Map<?o  Map<K,V> getAll(Set<?          extends K,? extends    e...
Cache メソッド	o  V getAndReplace           o  boolean    (K key, V value)              unregisterCacheEntryLo  void remove...
Cache Entry Expiration	o  キャッシュ中のエントリーは、最終更新時あるいは最終    アクセス時間に基づいて、エクスパイアする。    javax.cache.CacheConfiguration.ExpiryType...
Read-Through Caching	o  read-through キャッシュは、read-through ではな    いキャッシュと全く同じように振る舞う。ただ、エントリー    がキャッシュに見つからなかった場合、get()とge...
Write-Through Caching	o  Proxyである。どのような変化も、常に、CacheWriter    を呼び出す。o  write-through モードの時、    removeAllNoWriteThroughは、キ...
参考:eXtreme Scale  後書きキャシング	  o  後書きキャッシングは、ローダー・プラグインへの更新      情報を 非同期でキューに入れます。eXtreme Scale      トランザクションをデータベース・トランザクシ...
CacheLoader	o  CacheLoaderインターフェースは、キャッシュのプリ・ロ    ードと、キャッシュミス時の特別なアクションを可能とする    2つの場合に用いられる。o  後者の場合は、例えば、read-throughが...
CacheEntryListener	 n    CacheEntryCreatedListener n    CacheEntryUpdatedListener n    CacheEntryRemovedListener n    ...
Chapter 4 - Cache Managers
Cache Managers	o  CacheManagerは、キャッシュの集まりで    、そのコンテナーである。コンテナーとして、    それは、キャッシュのライフサイクルの全て    の局面を管理する。
Cache Managersの機能	1.  キャッシュを名前で見つけ出す機能2.  Transactionマネージャにとって、XA Resourceとして    働く。3.  キャッシュのユニットに対して設定の対応をする。4.  自身が起動され...
Cache Managersの機能	7.  デフォールトのキャッシュのテンプレートを提供し、新し    いキャッシュが意味のあるデフォールトで作られるよう    にする。8.  シングルトンとして、ただ一つのCacheManagerしか    ...
Construction	o  シングルトンのCacheManagerは、次のよ    うに構成され、参照される。  CacheManager.getInstance()o  インスタンスの構成    複数のCacheManagerのインス...
Default CacheManager	o  利用を簡単にするために、実装はデフォールトの    設定を提供すべきである。そうすれば、ユーザ    によって提供される実装に特有の設定ファイル    が無い場合でも、CacheManagerを...
Cache Configuration	Cache<Integer, String> myCache1 = cacheManager.      <Integer, String>createCacheBuilder("myCache1"). ...
simple example	String cacheName = "sampleCache"; CacheManager cacheManager = Caching.getCacheManager(); Cache<Integer, Dat...
o  boolean putIfAbsent(K key, V value)if (!cache.containsKey(key)) {   cache.put(key, value);   return true;} else {   re...
Interface CacheManager	o  <K,V> CacheBuilder<K,V> createCacheBuilder(String    cacheName)o  <K,V> Cache<K,V> getCache(St...
Interface CacheBuilder<K,V>	o  Cache<K,V>       build()o  CacheBuilder<K,V>    registerCacheEntryListener(CacheEntryList...
Interface CacheBuilder<K,V>	o  CacheBuilder<K,V>    setStatisticsEnabled(boolean enableStatistics)o  CacheBuilder<K,V>  ...
Interface CacheLoader<K,V>	o  CacheLoaderは、read-throughキャッシング    で利用され、データをキャッシュにロードする。o  Cache.Entry<K,V> load(K key)  ...
Interface CacheWriter<K,V>	o  CacheWriterは、 背後にあるリソースへの    write-throughキャッシングとwrite-behind     キャッシングで利用される。o    void  ...
Class Caching	o  JDKのServiceLoaderのSPI規約を利用して、    CacheManagers を生成する為のFactoryである。o  プロバイダが発見される為に、そのjarファイルは、次の    ように、...
Class Caching	o  もしも、一つ以上のCachingProviderが見    つかったら、 getCacheManagerFactoryは    、例外を投げる。	o  Cachingクラスはまた、このfactoryで生成さ...
Interface CachingProvider	o  CacheManager factory プロバイダによって実装される    べきインターフェース。 CacheManagerを生成する為に、    Cachingクラスによって呼び出...
キャッシュは、CacheManagerの中にある	o  キャッシュは、キャッシュ・クラスタとの統合のような    CacheManager の機能を必要とすることがある    ので、CacheManagerの外部で起動されてはな    らない...
Chapter 5 - Transactions
Transactions	o  トランザクションは、この仕様のオプショナルな    要件である。トランザクションは、JTA仕様で提    供された意味を持つ。もし、実装されれば、トラ    ンザクションはここで規定されたように動作する    ...
o  トランザクションを提供する動機は、キャッシュ    にとってデータベース、メッセージキュー、その他    のXAリソースと強い整合性を保ち続けることが    、しばしば、非常に重要になるからである。o  トランザクションのサポート無し...
XA Transactions	o  キャッシュのXAトランザクションは、JTAの    仕様と選択された隔離レベルに基づいて機    能する。o  XAトランザクションは、 Transaction    Managerの存在を必要とする。...
トランザクション・サンプル	//Get a global transaction assuming in a// Java EE app serverUserTransaction utxg =   jndiContext.lookup(“ja...
Enlistment	o  Enlistmentとは、トランザクション・マネージャが、あるX    Aリソースがあるトランザクションに参加しようとしてい    ると、それによって告げられるプロセスである。o  javax.transacti...
o  Enlistmentsは、    TransactionManager.getTransaction().enlistRes    ource(XAResource xaRes)を用いることで終了する。o  TransactionMa...
o  我々がコネクションを閉じることは無いので、    XAResource.end()が呼びだされることはない。o  我々は、two-phaseコミット・プロトコルがはじまる前に    トランザクション・マネージャが、我々の為にend()...
o  JTAの仕様は次のことを要求している。    「同一のリソースを使って、複数のトランザクション・コン    テキストをインターリーブすることは、それぞれのトラン    ザクション・コンテキスト・スイッチに対して    XAResourc...
o  もしXAResourceがCacheManagerのレベルにあった    とすると、我々は、endを呼び出さないのだから、このこ    とは、CacheManagerをまたいでは、同時には、一つ    のトランザクションのみが実行可能で...
o  可能な別の実装は、キャッシュの操作のたびごとに、    XAResourceを生成することである。これは、高い並列    性を実現するが、より多くの、高価なenlistResource()    メソッドの呼び出しを要求する。
Recovery	o  Cachesは、JTAで定義されている、リカバリー・プロトコ    ルを実装しなければならない。特に、    XAResource.recover()は、必ず、サポートしなけれ    ばならない。o  永続するストア...
o  このことは、待機中のトランザクションが、他の    XAResourcesに対して、正しくリカバーされることを妨    げはしないだろう。さらに、ローカル・キャッシュは、読み    出しのいかなる試みに対しても空なので、影響される値  ...
Local Transactions	o  トランザクションをサポートするキャッシュは、4つの隔離    レベルを持つローカル・トランザクションをサポートする    だろう。o  ローカル・トランザクションは、トランザクション・マネージ  ...
o  このことは、CacheManagerに対する複数の変更を、    全て、単一のトランザクションで適用させることになる。o  もし、データベースのような他のリソースに対して変更を    適用することも望むなら、それらに対するトランザクシ...
o  JTA APIは、ローカル・トランザクションのコントロール    に使用される。o  javax.transaction.UserTransactionインターフェー    スは、アプリケーションにトランザクション境界をプログ    ...
//Get a transactionUserTransaction utx =   cacheManager.getUserTransaction();// start a transactionutx.begin();// do workc...
o  全てのローカル・トランザクションに関しての、ベスト・プ    ラクティスは、これらのステップを、try-catchブロックの    中に置いて、もし、例外が投げられたら、rollback()を    呼ぶことである。(詳細は、JTAの仕...
o  単一のスレッドが、XAトランザクションとローカル・トラン    ザクションを開始することは可能である。キャッシュ操    作は、トランザクション・コンテキストが存在する故に、X    Aならびにローカルなトランザクション・キャッシュの双...
//Get a local transactionUserTransaction utxl = cacheManager.getUserTransaction();//Get a global transaction assuming in a...
o  ローカル・トランザクションは、すべてCacheException    のサブクラスである、自身の例外を持っている。o  TransactionException   n  一般的な例外o  TransactionInterrup...
Recovery	o  Recoveryは、XAトランザクションに関連している。 Tロ    ーカル・トランザクションでは、コミット以前にクラッシュし    た場合、変化は、隔離レベルにディペンドする。
Chapter 6 - Isolation Levels
Isolation Levels	o  キャッシュの隔離レベルは、生成時に設定され、そ    のキャッシュのライフサイクルを通じて、変更不能なまま    にとどまる。  隔離レベルには、次の4つがある。o  READ_COMMITTEDo...
READ_COMMITTED	o  内容の変化は、COMMIT が呼ばれるまで、ローカル    ・キャッシュでも分散キャッシュでも、他のトランザクショ    ンには見えない。o  その時まで、次のいずれかの実装が自由である。  n  古い...
READ_UNCOMMITTED	o  キャッシュの変化は、ローカル・キャッシュでも分散キャ    ッシュでも、実装上の伝搬の遅延に従いながら、トラン    ザクションが利用されなかったように、ただちに他のトラ    ンザクションに見える。o...
SERIALIZABLE	o  内容の変化は、COMMIT が呼ばれるまで、ローカル    ・キャッシュでも分散キャッシュでも、他のトランザクショ    ンには見えない。o  さらに、他のトランザクションによって起こされたキャッシ    ュ...
o  An alternative is to exclusively write lock a    collection of keys of interest before starting    your transaction. W...
REPEATABLE_READ	o  Mutating changes are not visible to other    transactions in a local cache or a distributed    cache u...
Chapter 7 –Caching Annotations
Caching Annotations	o  この章では、Java Caching 1.0 仕様で定義された、    アノテーションについて議論する。アノテーションは、こ    の仕様のオプショナルな部分であり、独立したライブ    ラリーと...
Annotations Overview	o  アノテーションとそのサポートクラスは、    javax.cache.annotationパッケージに    ある。
Annotation Inheritance andOrdering	o  この仕様は、アノテーションの継承について、Java仕様の    Common Annotations の2,1節に従っている。o  この仕様外のアノテーションに関す...
Multiple Annotations	o  一つのメソッドには、一つのメソッド・レベルのキャッシ    ング・アノテーションのみが指定でき、パラメータでは、    一つのパラメータ・レベルのアノテーションのみが指定    出来る。o  ...
@CacheDefaults	o  @CacheDefaultsは、クラス内で利用されるキャッシン    グに関連した全てのアノテーションのデフォールトのプ    ロパティの値を定義するのに用いられる、クラス・レベル    のアノテーションで...
o  次の例は、このクラスのキャッシュのデフォールトとして    利用される、”cities”という名前のキャッシュを指定して    いる。o  getCityメソッドの、@CacheResultアノテーションは、    実行時にこのキャッ...
package my.app;@CacheDefaults(cacheName="domainCache")public class DomainDao { @CacheResult public Domain getDomain(String...
@CacheResult	o  @CacheResultは、メソッド・レベルのアノテーションで    ある。その返り値がキャッシュされることを、メソッドにマ    ークする為に用いられる。この時、キーは、メソッド・パ    ラメータから生成さ...
o  オプション  1.  cacheNullプロパティを通じて、返り値nullのキャッシュをコン      トロールする  2.  オプショナルなキャッシングと名前を持つキャッシュ自身の例外      の再発行。キャッシュ固有の例外の機能を...
package my.app;public class DomainDao { @CacheResult public Domain getDomain(String domainId, int index) {    ... }}	packa...
@CachePut	o  @CachePutは、メソッド・レベルのアノテーションで、そ    のメソッドの引数の一つがキャッシュに格納されるべきこ    とをマークする。一つの引数は、それがキャッシュされ    るべきことを示す為に、@Cac...
o  オプション  1.  cacheNullプロパティを通じて、返り値nullのキャッシュをコン      トロールする  2.  Cache.putの呼び出しが、このメソッドの実行以前、あるいは      実行後に起きるのかを指定する。 ...
@CachPutでアノテートされたメソッドが呼び出された時、CachKeyが生成され、指定されたキャッシュ上でCache.put(Object, Object)が呼び出され、@CacheValueでマークされた値を、キャッシュに格納する。Nul...
@CacheRemoveEntry	o  @CacheRemoveEntryは、メソッド・レベルのアノテーシ    ョンで、エントリー中のメソッドの呼び出しの結果が指定さ    れたキャッシュで削除されることをマークする。o  @Cache...
package my.app;public class DomainDao { @CacheRemoveEntry(cacheName="domainCache") public void deleteDomain(String domainI...
@CacheRemoveAll	o  @CacheRemoveAllは、メソッド・レベルのアノテーショ    ンで、メソッドの呼び出しの結果のエントリー全てが、指    定されたキャッシュで削除されることをマークする。o  オプション  1...
デフォールトの振る舞いでは、アノテートされたメソッドが呼び出された後に、Cache.removeAll()が呼ばれる。この振る舞いは、afterInvocation() をfalseにすることで変更出来る。この場合、Cache.removeAl...
@CacheKeyParam	o  @CacheKeyParamは、パラメータ・レベルのアノテ    ーションで、パラメータがCacheKeyGeneratorを通じて    CachKeyを生成するのに利用されることをマークする。o  実...
@CacheValue	o  @CacheValueは、パラメータ・レベルのアノテーショ    ンで、@CachePutでアノテートされたメソッドの、キャ    ッシュされるべきパラメータをマークするのに用いられる。    @CachePut...
Cache Resolution	o  メソッド・レベルのアノテーションは、全て、    CacheResolverFactory の仕様とキャッシュを決定す    る為に用いられるキャッシュの名前が、実行時に相互    に作用することを可能...
Cache Name	o  もし、キャッシュの名前が、メソッド・レベルのアノテーシ    ョンでも、@CacheDefaults アノテーションでも指定さ    れていなければ、名前は、次のように生成される。o  package.name....
CacheResolverFactory	o  指定されたCacheResolverFactoryは、 毎回のアノテー    トされたメソッドの呼び出しのたびに利用される    CacheResolverを決定する為に、アノテートされたメソッ...
o  デフォールトの CacheResolverFactoryのルール:  1.  Caching.getCacheManager()を通じて、利用する      CacheManager を取得する。  2.  キャッシュの名前で、Cach...
CacheResolver	o  CacheResolverは、CacheResolver ファクトリーによ    って返えされる。このことは、それが返されるアノテート    された全てのメソッドの呼び出しのたびに、 呼び出され    、この...
Key Generation	o  @CacheResult, @CachePut,    @CacheRemoveEntryアノテーションは、全て、キャ    ッシュ・キーが生成されることを要求する。これらのア    ノテーションの全ては、...
o  開発者がキーで利用されるように指定した、メソッドのパ    ラメータは、getKeyParameters() メソッドで返される    CacheInvocationParameterアレーに含まれる。カス    タムのCacheKey...
o  デフォールトのCacheKeyGeneratorのルール:  1.  CacheKeyInvocationContext.getKeyParameters()で      返されたアレーから、      CacheInvocationP...
Annotation Support Classes	o  CacheMethodDetails  n  キャッシング・アノテーションを持つメソッドについての、Static      な情報。実行時に、CacheResolverFactor...
o  CacheKeyInvocationContext  n  @CacheResult, @CachePut, @CacheRemoveEntryの      いずれかでアノテートされた、キー生成が行われるメソッドの実      行に関...
o  CacheKey  n  CacheKeyGeneratorインターフェースによって生成される。      CacheKey は、アノテーションによって相互作用する全て      のキャッシュのキーとして利用される。全てのCacheK...
Chapter 8 - Container andProvider Contracts for Deploymentand Bootstrapping
Container and Provider Contracts forDeployment and Bootstrapping	o  Java SEの環境では、    CacheManagerFactory.getCacheManagerメ...
o  プロバイダーの設定ファイルは、プロバイダの実装クラ    スを、そのプロバイダをキャッシュ・マネージャのファク    トリーとして位置づけて、CacheManagerFactory ブ    ートストラップ・クラスに、エキスポートする役...
o  Example:o  A persistence vendor called ACME caching    products ships a JAR called acme.jar that    contains its cach...
o  The contents of the META-INF/services/    javax.cache.spi.CacheManagerFactoryProvider    file is nothing more than the...
o  If more than one provider jar is registered the    first one found by java.util.ServiceLoader will    be used. If no p...
Use of Caching	o  The API provides a static means of accessing    caching support through the class    javax.class.Cachin...
Chapter 9 - Glossary
o  CacheManager A container for caches, which    holds references to them.o  Cache A collection of related items.o  Cac...
o  CacheWriter A user-defined Class which is    used to write key/value pairs into a cache after    a put operation.o  C...
Resin 4.0 jcache(distributed caching)
public class MyServlet extends GenericServlet { @Current Cache _cache;    public void service(ServletRequest req, ServletR...
<web-app xmlns="http://caucho.com/ns/resin"        xmlns:cluster="urn:java:com.caucho.cluster"> <cluster:ClusterCache name...
Maven Snippet	<dependency>   <groupId>javax.cache</groupId>   <artifactId>cache-api</artifactId>   <version>0.3</version><...
Creating a CacheManagerCacheManager cacheManager = Caching.getCacheManager();CacheManager cacheManager = Caching.getCacheM...
o  We expect implementations to have their own    well-known configuration files which will be    used to configure the C...
Creating a CachecacheManager = getCacheManager();CacheConfiguration cacheConfiguration =   cacheManager.createCacheConfigu...
Getting a reference to a Cache	o  You get caches from the CacheManager. To get    a cache called “testCache”:Cache<Intege...
Basic Cache Operations	o  To put to a cache:Cache<Integer, Date> cache =      cacheManager.getCache(cacheName);    Date v...
o  To remove from a cache:Cache<Integer, Date> cache =  cacheManager.getCache(cacheName);  Integer key = 1;  cache.remove...
Annotations	o  The JSR107 annotations cover the most    common cache operations including:  n  @CacheResult – use the ca...
public class DomainDao {    @CachePut(cacheName="domainCache")    public void updateDomain(String domainId,        @CacheK...
Annotation Example	public class BlogManager {@CacheResult(cacheName="blogManager")public Blog getBlogEntry(String title) {...
Wiring Up Spring	<jcache-spring:annotation-driven proxy-target-class="true"/>A full example is:<beans ...> <context:annota...
Wiring Up CDI	o  First create an implementation of    javax.cache.annotation.BeanProvider and then    tell CDI where to f...
Resin 4.0 jcache (distributed    caching)	public class MyServlet extends GenericServlet { @Current Cache _cache;    public...
configuration	<web-app xmlns="http://caucho.com/ns/resin"        xmlns:cluster="urn:java:com.caucho.cluster"> <cluster:Clu...
Java EE7 䛸㻌JCache 
Java EE7 䛸㻌JCache 
Java EE7 䛸㻌JCache 
Java EE7 䛸㻌JCache 
Upcoming SlideShare
Loading in …5
×

Java EE7 䛸㻌JCache 

3,099 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,099
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
17
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Java EE7 䛸㻌JCache 

  1. 1. Java EE7 と JCache @maruyama097 丸山不二夫
  2. 2. はじめに o  筆者の基本的な問題意識は、ネットワーク上のマーケッ トが急速に拡大するという展望の中で、エンタープライズ ・システムを、もっと高速でスケーラブルなものにしつつ、 トランザクションの正確性をきちんと担保することである。o  そこでは、キャッシュ技術は欠かせない。 事実、分散キャッシュについては、多くの商業製品、オ ープンソースのプロジェクトが登場し利用されている。に もかかわらず、エンタープライズJavaの標準的なキャ ッシュ技術というべきものは、存在しなかった。o  その点で、Java EE7の仕様の一つとして、エンタープライ ズJavaの標準的なキャッシュ技術となるべく検討されて いる、JCacheに、注目している。
  3. 3. はじめに o  プレゼンの前半で、同じキャッシュというくくりで、CPUと メモリーの間に置かれている、キャッシュの問題について Cliff Clickの議論の紹介をした。もっとも、これは、キャ ッシュが有効に機能していないという例なのだが。o  また、CPUのMulti-core化が、キャッシュにとってどうい う意味を持つかを考えてみた。意外と複雑で、残念な がら、すっきりした見通しは持てなかった。o  現在のJCacheの仕様には、分散キャッシュの実装、あ るいは、そのインターフェースの利用について、明示的 な言及は無い。昨年、立ち上がった、JSR 347: Data Grids for the JavaTM Platform が、その一つの答 えだと思うのだが、今後の進展を注目している。
  4. 4. Agenda o  CPUとキャッシュo  Multi-Core CPUとメモリーo  システムの階層性とキャッシュo  WebアプリのScale-outと 分散メモリーキャッシュ、NoSQLo  JSR 347: Data Grids for the JavaTM Platformo  JSR 107: JCACHE - Java Temporary Caching API
  5. 5. CPUとキャッシュ Not Your Fathers Von Neumann Machine:A Crash Course in Modern Hardware Cliff Click Azul Systems Brian Goetz Sun Microsystems http://www.azulsystems.com/events/javaone_2009/ session/2009_J1_HardwareCrashCourse.pdf から
  6. 6. CPU Performance Multicore era Frequency scaling era CISC era
  7. 7. CPUとメモリーのスピードのギャップ o  CPUとメモリーのスピードのギャップは拡大している。か つてのCPUのメモリーアクセスは、レジスターのフェッチ よりほんの少し遅いだけだった。今日では、メイン・メ モリーからのデータの取り込みは数百クロック・サイクル を要する。 http://t.co/PekDYDFf
  8. 8. CPUのキャッシュ o  かつては、乗算は高価な処理で、メモリーからのLoad は安価な処理だった。しかし、今では、乗算は安価な処 理で、メモリーからのLoadは、高価な処理である。 o  CPUとメモリーのスピードのギャップが広がる中で、今日 のCPUは、洗練された多段のキャッシュを発展させて きた。ただ、CPUのパフォーマンスに、決定的な影響を 与えるのは、CPUの実行スピードではなく、キャッシュ・ ミスなのである。o  Static RAMは、高速だが高価である。Dynamic RA Mは、安価だが低速である。CPUのキャッシュとは、高速 のSRAMをCPUの近くに配置して、メモリーのパフォー マンスを良くしようと言うもの。
  9. 9. コードとデータの局所性 o  キャッシュが効くのは、多くのプログラムのコードもデー タも「局所性」を持つから。コードとデータは、それぞれ 固有の「局所性」を持つので、コードのキャッシュとデー タのキャッシュの両方が必要である。
  10. 10. データをCPUの近くに置く o  「データをCPUの近くに置くこと!」 メモリー遅延の最 大の要因は、伝送線の遅延である。ここでは、情報伝 達の上限である光のスピードが問題になる。1GHzの CPUの1クロックの間に、信号は、光のスピードでも、 30cm以上を進むことが出来ない。o  CPU-メモリーのスピードギャップが広がるにつれ、多段 のキャッシュが必要になってきた。ただレジスタへのアク セスが、1クロック以下で可能なのに対して、L1キャッシュ は3clk、L2キャッシュは15clk、メモリーアクセスには 200clk必要 http://t.co/pmEqEmt9
  11. 11. メモリーは、新しいディスク o  キャッシュミスの確率は、現在ではかなり低い。ただ 、キャッシュミスによって、100〜1000命令分の時間の コストが発生する。だから、キャッシュミスの確率が5% 前後だとしても、パフォーマンスに対するインパクトは 、キャッシュミスの方が大きなものになる。 o  CPUとメモリーのスピードのギャップが拡大するにつ れて、キャッシュミスがCPUのパフォーマンスを決める といってもいいのだ。「いまや、メモリーは、新しいディス クなのだ。」
  12. 12. Multi-coreとキャッシュ o  Multi-coreのシステムでは、最下層のキャッシュは、い くつかのコアで共有されている。o  しかし、全てのキャッシュが、全てのコアから見える訳で はない。
  13. 13. Multi-Core CPUとメモリー
  14. 14. http://www.socip.org/socip/speech/pdf/20110708-080436-Perfectvips-SoCIP%202011%20Presentation.pdf わずか10年の間のトランジスタ数の変化
  15. 15. Multi-Coreのコア数とトランジスター数 コア数 トランジスター数 CPU 2 300M Apple A5 10 2600M Westmere EX 48 1300M SCC 100 500M Tile GX 100
  16. 16. Multi-Coreのコア数と外部メモリー o  コアの数が増えても、そのチップからアクセス可能なメモリ ーの量は、コアの数に比例して増えていく訳ではない。‎10 0コアのTilera TileGX100が、10コアのWestMere-E Xの、10倍のメモリー空間を持つ訳ではない。o  Multi-Coreチップの外部メモリーの量は、コアの数では なく、そのチップが何個のメモリー・コントローラを持ってい るかで上限が決まっている。4個のメモリーコントロラーをも つSCCのメモリーは、4x16の64G「しか」ない。o  そこは、コモディティ化したノードをメモリー、ディスクごと 増やしていく、これまでのスケールアウト・アーキテクチャ ーのメモリーの計算の仕方とは、異なる。
  17. 17. SCCのメモリー構造 共有外部メモリー(可変長) コア毎の L2 L1 コア毎の L2 L1外部メモリ Cache Cache cpu_0 外部メモリ Cache Cache cpu_47 (可変長) 256K 16K (可変長) 256K 16K チップ上の共有メッセージ・パッシング・バッファー 384K 8K/core
  18. 18. SCCの共有仮想メモリー空間 o  コアをまたいだ、共 有仮想空間が利用 アプリケーション できる。o  アプリケーションか 共有 仮想メモリー ら見ると、単一のメ モリー空間に見える。o  複数のcore間で 、シームレスにデー タ構造やポインター を共有できる。 基本的に、Parallel型の利用法
  19. 19. SCCの物理アドレス o  SCCのそれぞれのコアは、32ビット(4GB)のア ドレス空間を持っている。o  通常は、物理アドレスは、FSB(Front Side Bus)上に見える。o  SCCでは、物理アドレスは、十分ではない。 64GBのメモリーと、無数のSCCシステム・アドレ ス(12bit+34bit)がある。o  物理アドレスをSCCシステム・アドレスに変える 変換器が必要である。
  20. 20. 48コアが、4つのメモリーコントローラを持つ。デフォールトでは12コアに一つのコントローラが割り当てられている。
  21. 21. In-Memory CommunicationMechanisms for Many-Cores -Experiences with the Inte SCC http://communities.intel.com/docs/DOC-19423
  22. 22. Efficient Memory Copy Operations onthe 48-core Intel SCC Processor http://dare.uva.nl/document/356252
  23. 23. システムの階層性とキャッシュ
  24. 24. 処理スピードで規定される階層性 o  システムの階層性を規定しているのは、処理のスピード である。次のような階層がある。 CPU > メモリー > ディスク > ネットワークo  キャッシュは、基本的には、階層間をつなぐ働きをする。 n  CPU/メモリー: L1,L2キャッシュ n  メモリー/ディスク: nio、mmap。ディスクのメモリー・キャッシュ。 SSD。 n  メモリー/ネットワーク: ... n  ディスク/ネットワーク: ...
  25. 25. メモリーのコストの階層性 o  処理スピードの階層性の他に、コストの階層性がある。 基本的には、処理スピードの階層性を裏打ちしているよ うにも見えるが、本来は、別の原理である。 SRAM > DRAM > SSD > Disko  SRAMのように高速で、DRAMのように安価なメモリー が登場すれば、アーキテクチャは、大きく変わりうる。
  26. 26. ネットワークのスピードとコスト o  こうした処理スピードとコストの階層性は、固定的なもの では無い。ネットワークの処理スピードは向上し、コスト は低下しうる。もし、次のようになったら? CPU = ネットワーク > メモリー > ディスクo  Gilderは、かつて、次のように述べていた。 ネットワークがコンピュータの内部バスと同じぐらい早くな れば、マシンは、特定の目的を持ったデバイスのあつま りへとネットワーク上で分解するだろう。
  27. 27. ディスクの価格低下のインパクト Hard Disk 半導体のMoore則 ディスクの価格低下 ディスク1G 5円 http://www2s.biglobe.ne.jp/~sakharov/index.html
  28. 28. ACM 2012The Future of Microprocessors o  プロセッサのパフォーマンスの新しい基本的な制限が、 エネルギー効率だと言う視点からの分析。o  今日のプロセッサのパフォーマンスは、毎秒100Giga- opのオーダーである。パフォーマンスは、次の10年で3 0倍になり、毎秒3Tera-opに達するであろう。o  少なく見積もっても、この時、9T-オペランド、すなわち 64b × 9T-オペランド (576T-bits!) が、毎秒、レジ スター/メモリーから演算器等に移動するのだが、それ はエネルギーを消費する。http://delivery.acm.org/10.1145/1950000/1941507/p67-borkar.pdf
  29. 29. o  もしもオペランドが平均して1mm (ダイサイズの10%) 移動するとして、0.1pJ/bitの割合だとすると、576T-bit sの移動は、約58ワットを消費することになり、計算に 必要なエネルギーは、ほとんど残っていない。o  Many-coreシステムのコアは、コアとコアの間を、チッ プ上のネットワークを通じてデータが移動する。o  オペランドの10%がネットワーク上に流れ、平均10ホッ プで移動するとして、0.06pJ/bit としてネットワークの 電力消費は、35ワットになり、プロセッサーに割り当て られている電力の半分以上を消費することになる。
  30. 30. WebアプリのScale-outと分散メモリーキャッシュ、NoSQL
  31. 31. Web Appli Multi-tier のScale-out戦略 Daa Base Web Server  Business Logic
  32. 32. Web Appli Multi-tier のScale-out戦略 Web Server Business Logic Load Balancer Daa Base ・・・・・・・
  33. 33. Web Appli Multi-tier のBottle Neck Web Server Business Logic Load Balancer Daa Base ・・・・・・・
  34. 34. Multi-tier の分散メモリーCache Web Server Business Logic Load Balancer Daa Base ・・・・・・・
  35. 35. Cloud上の分散データベース On Memory Persistency Hash
  36. 36. 分散キャッシュのプロダクト o  市場には、多くの分散キャッシュのプロダクトが、存在し ている。o  代表的なものをあげれば、 OracleのCoherence (Cameron Purdy)、 IBMのeXtreme Scale (Billy Newport)、 TerracottaのEhCache (Greg Luck)、 MicrosoftのAppFabric。o  もちろん、低レーヤでは、オープンソースのmemcache dが広く利用されている。日本発のキャッシュ技術も、優 れたものがある。 n  個人的には、JSR107のEGに、Cameron Purdy、Billy Newport、Greg Luckの三人が入っているのに、期待している。
  37. 37. キャッシュとNoSQLの比較 o  キャッシュは、Key/Value。 NoSQLのあるものは、Key/Value。o  キャッシュの主目的は、パフォーマンス。 NoSQLの主目的は、永続性。o  キャッシュは、永続性を持ちうる。 NoSQLは、常に永続性を持つ。o  永続するキャッシュは、NoSQLのユースケー スの一部をカバーする。NoSQLのあるものは 、キャッシュのユースケースをカバーする。
  38. 38. キャッシュとNoSQLの比較 o  キャッシュのサイズは小さい。〜数十GB NoSQLのサイズは、数TB〜数PBo  キャッシュはメモリーに置かれる。 NoSQL、RDBMSは、ディスクに置かれる。o  キャッシュは、メモリー上のデータストア。 NoSQLは、Relation無しのDBMS。
  39. 39. JSR 347: Data Grids for theJavaTM Platform
  40. 40. Description o  この仕様は、分散データグリッドに、アクセスし、格納し 、データを管理するAPIを提供することを目的としたもの である。o  最初のAPIは、JSR-107 (JCACHE) APIの上に、そ の拡張として構築されるだろう。JSR-107は、キャッシ ュにアクセスする一般化されたMAPに似たAPIに加えて 、イン・メモリーのデータをパーシステントなストレージに スプールするSPI、CacheManagerから名前のついた Cacheを取得するAPI、イベント・リスナーを登録するAP Iを定義している。
  41. 41. o  JSR-107の上にそれを超えて、このJSRは、権限の引 き渡し、複製化、分散、トランザクション(JTAの仕様に 基づいて)の特徴と期待される特質を定義するだろう。o  さらに、非同期で、ノンブロッキングなAPIを、JSR-107 の最初のAPIに変わるものとして定義するだろう。とい うのも、データに対するノンブロッキング・アクセスは、デ ータグリッドのように、リモート呼び出しを実行する必要 のある実装では、関心事になるからである。
  42. 42. o  この仕様は、まだ完成していないJSR-107の上に構築 される。我々は、彼らのスケジュールが、このJSRのス ケジュールと両立出来ることを保証する為に、JSR-107 のEGと、ともに作業する意向である。もし、JSR-107が 完成することが出来なければ、最後の利用可能なドラフ トを、この仕様にマージすることを提案する。
  43. 43. Proposed features o  Async API (Future based) public interface AsyncCache<K, V> { Future<V> get(K key); Future<Void> put(K key); Future<V> getAndPut(K key); Future<Boolean> remove(K key); Future<V> getAndRemove(K key); ... etc ... }
  44. 44. Proposed featureso  Distributed code execution n  Map/Reduce n  Alternate proposalo  Group APIo  CDI (Contexts and Dependency Injection) integrationo  Transactions (JTA) integrationo  Operation Modeo  Eventually Consistent API
  45. 45. Proposed features o  Configurationo  Drop-In Replacement for JSR-107 Compliant Caches
  46. 46. JSR-347 Spec LeadManik Surtani氏とのインタビュー o  JSR 347はJavaプラットフォーム向けのデータグリッド としても知られていますが、APIとプログラミングモデル 、そしてフォルトトレラントなインメモリの分散キーバリュ ーストアの振る舞いについて標準化するために提案さ れたものです。JSR 107 (Javaプラットフォーム向け一 時キャッシュ)との違いはたくさんあります。o  データの永続性。JSR 347はレコードの保存機構であり 、本質的な分散の仕組みによって耐久性を提供します 。一方、JSR 107は一時的で揮発性の高いデータを保 存する前提の仕様です。 http://www.infoq.com/jp/news/2011/10/java-data-grid
  47. 47. JSR-347 Spec LeadManik Surtani氏とのインタビュー o  分散。JSR 107の実装は分散化されていてもかまいま せん。一方、JSR 347の実装は分散化されていなけれ ばなりません。従って、JSR 347の方がデータストアの 使い勝手を向上させるためにより機能豊富なAPIを提供 します。例えば、グリッド上のデータの保存場所を制御す るAPIや非同期のノンブロッキングAPI、実装の一貫性 をサポートするAPIは、実装が分散化されているというこ とを知っていなければ意味がありません。
  48. 48. JSR-347 Spec LeadManik Surtani氏とのインタビュー o  Map/Reduceと分散コード実行。データがグリッド上に分 散/パーティションされている場合、コードの実行をデー タ側に移動させた方が他の方法よりも合理的な場合が あります。JSR 347はこのようなことを実現するAPIも 提供する予定です。
  49. 49. JSR-347に対するVMWareの反対意見 o  VMware has serious concerns around the proposed JSRs relationship with JSR-107. While we note that some other EC members hope that the necessary harmonization can occur after the approval of this JSR, we would prefer to see such discussions take place before another potentially competing JSR is approved, and see that path as less risky.
  50. 50. JSR-347に対するVMWareの反対意見 o  We do believe that this area is important and warrants interest from the JCP. The JSR-347 proposal includes useful functionality, but raises a serious risk of fragmentation and confusion.o  We would prefer to see JSR-107 brought swiftly to a conclusion without excessive scope creep, allowing a new JSR then to be presented building upon it.
  51. 51. Object Caching for Java Functional Specification for Object Caching Service for Java (OCS4J), 2.0 http://jcp.org/aboutJava/communityprocess/jsr/ cacheFS.pdf
  52. 52. Objectの三つのタイプ 1.  決して変化しないオブジェクト n  staticで初期化すればいい2.  ユニークで使い捨てのオブジェクト n  使うたびにnewすればいい3.  上記2つの中間のオブジェクト n  Javaは、先2つのタイプのオブジェクトは簡単に扱え るが、第三のタイプのオブジェクトを扱うのは不便。「第三のタイプ」とは、複数のリクエストをまたいで、ユーザーの間やプロセスの間で、 変化し共有されうる情報やオブジェクト。
  53. 53. Object Caching Service for Java(OCS4J) の目的 o  Caching Service for Java (OCS4J)の目 的は、アプリケーションが、リクエストやユーザ ーやプロセスをまたいで、オブジェクトを共有す ることを可能にすること。o  このシステムは、任意のJavaオブジェクトを扱う ことが出来る。全てのオブジェクトは、「名前」 によって位置づけられ、プロセス中の全ての スレッドによって共有される。
  54. 54. キャッシュされたオブジェクトのLife Cycle o  オブジェクトの生成 n  ユーザーが定義したLoaderで行われる n  不要な生成を避ける為に、キャッシュシステムと の協調が必要o  オブジェクトの無効化 n  アプリから明示的に行うことも可能 n  “time to live” あるいは “idle time” に関連して n  キャッシュシステムの容量オーバー(設定可能)o  オブジェクトの削除
  55. 55. キャッシュされたオブジェクトのLife Cycle o  オブジェクトの削除 n  最近使われていないオブジェクト n  削除されたオブジェクトは、ディスクにスプール可能 n  スプールの決定は、ユーザーが定義したオブジェク トの属性によるo  コールバック n  オブジェクトがキャッシュシステムで無効化あるいは 削除された時、登録されたコールバック・メソッドを呼 び出すように出来る。
  56. 56. キャッシュとプロセス o  システムの単純性、可用性、パフォーマンスの 為に、オブジェクト・キャッシュは、それぞれのプ ロセスに結びつけられている。o  キャッシュ・システムでのオブジェクトの生成 には、中央からのコントロールといったものは 存在しない。o  しかし、オブジェクトの更新と無効化については プロセス間の調整がある。 n  あるプロセスでオブジェクトが更新あるいは無効化 された時、その名前と関連情報は、他の全てのキャ ッシュのインスタンスにブロードキャストされる。
  57. 57. GAEでのJCache の利用
  58. 58. Cache インスタンスの取得 Cache cache; try { CacheFactory cacheFactory = CacheManager.getInstance().getCacheFactory(); cache = cacheFactory.createCache(Collections.emptyMap()); } catch (CacheException e) { // ... }
  59. 59. 値の設定と取得 String key; // ...         byte[] value; // ... // Put the value into the cache. cache.put(key, value); // Get the value from the cache. value = (byte[]) cache.get(key);
  60. 60. 有効期限の設定 Cache cache; Map props = new HashMap(); props.put(GCacheFactory.EXPIRATION_DELTA, 3600); try { CacheFactory cacheFactory = CacheManager.getInstance().getCacheFactory(); cache = cacheFactory.createCache(props); } catch (CacheException e) { // ... }
  61. 61. 値の有効期限は次のプロパティで制御 o  GCacheFactory.EXPIRATION_DELTA: 値を設定 した時点から有効期限までを秒数で指定する整数値 o  GCacheFactory.EXPIRATION_DELTA_MILLIS: 値を設定した時点から有効期限までをミリ秒数で指定 する整数値 o  GCacheFactory.EXPIRATION: 有効期限の日時を 指定する java.util.Date
  62. 62. 設定ポリシーの設定 Map props = new HashMap();props.put(MemcacheService.SetPolicy.ADD_ONLY_IF_NOT_PRESENT,true);
  63. 63. o  MemcacheService.SetPolicy.SET_ALWAYS: キ ーに値が存在しない場合は値を追加し、そのキーの値 が存在する場合は既存の値を置き換えます。これが デフォルトの設定です。 o  MemcacheService.SetPolicy.ADD_ONLY_IF_NO T_PRESENT: キーに値が存在しない場合は値を追 加し、そのキーの値が存在する場合は何も実行しま せん。 o  MemcacheService.SetPolicy.REPLACE_ONLY_IF _PRESENT: キーに値が存在しない場合は何も実行 せず、そのキーの値が存在する場合は既存の値を置き 換えます。
  64. 64. キャッシュの統計 CacheStatistics stats = cache.getCacheStatistics(); int hits = stats.getCacheHits(); int misses = stats.getCacheMisses();
  65. 65. サポートされていない JCache 機能 o  JCache Listener API は、onPut リスナや onRemove リスナなど、アプリケーションの API 呼び 出しの処理中に実行できるリスナについては一部サポ ートされています。onEvict など、バックグラウンド処理 が必要なリスナはサポートされていません。 o  アプリケーションは、キャッシュ内に指定のキーがある かどうかをテストすることはできますが、指定の値があ るかどうかはテストできません(containsValue() は サポートされません)。 o  アプリケーションでキャッシュのキーまたは値の内容を ダンプすることはできません。 o  アプリケーションで手動でキャッシュの統計をリセットす ることはできません。
  66. 66. o  非同期のキャッシュ読み込みはサポートされていません。 o  put() メソッドは、キーの以前の値を認識していても値 を返さず、常に null を返します。
  67. 67. JSR107 JCache 仕様 「一時的なメモリー内のJavaオブジェクト のキャッシングのAPIとセマンティックスを規 定する。オブジェクトの生成、共有アクセス、 スプーリング、無効化、複数のJVMをまたい だ整合性を含む。」
  68. 68. 経緯 o  2001年5月 JSRスタートo  2003年12月 CoherenceのCameron Purdy、 Spec Leadにo  2007年5月 EhCacheのGreg Luck、co-Spec Leadにo  2012年4月 新しい体制Brian Oliver (Oracle), Cameron Purdy(Oracle), Greg Luck,..., Billy Newporto  Early Draft 1, still in progress. https://github.com/jsr107/jsr107spec
  69. 69. 現時点でのRIに 含まれているパッケージ o  javax.cacheo  javax.cache.annotationo  javax.cache.evento  javax.cache.mbeanso  javax.cache.spio  javax.cache.transaction https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cache
  70. 70. Chapter 1 - Introduction
  71. 71. 目的 o  キャッシングは、アプリを劇的にスピードアップする、試 されずみの、真実の方法である。o  アプリは、生成するのに高価だが再利用可能なライフタ イムを持つ一時的なデータを、しばしば、使うことがある。o  例えば、サーブレットは、複数のデータベース、ネッチワ ークのコネクション、そして高価な計算から得られるデー タから、Webページを生成する。これらのデータセットは 、同じ、あるいは異なった時間のあいだ、再利用可能か もしれない。
  72. 72. o  この仕様は、Javaオブジェクトのキャッシングの標準化 を行い、その効果的な実装を可能とし、キャッシュのエ クスパイア、相互排他制御、スプーリング、キャッシュの 整合性といったものを実装する重荷を、プログラマーか ら取り除くようにしようとするものである。
  73. 73. 目標 o  Object Cache: このAPIは、Javaオブジェクトをキャッシュする。o  Support for By-Value caching and optionally, By-Reference. 後者の参照はヒープの中に、前者では、キーと値は、 両方とも、値に変換される。o  Support for Flexible Implementations 仕様は、プロセスでの実装と、分散での実装の両方を サポートする。
  74. 74. o  Java SE  この仕様はJava SEのもとで機能する。o  Java EE この仕様は、Java EEのもとで機能する。この仕様は、 Java EE7に含まれることを目標としている。o  Annotations この仕様は、ランタイムのキャッシュ・アノテーションを定 義する。o  Transactions トランザクションのオプショナルなサポート。ローカルとX Aの双方が定義される。
  75. 75. Chapter 2 - Caches
  76. 76. キャッシュとは? o  キャッシュは、一時的なデータを格納する場所 である。それは、Mapに似たAPIを提供する。 Mapと同様に、データはキーの値として格納さ れる。o  データは、Mapと同じく、ユニークな識別子であ るキー経由でアクセスされる。与えられたキー に対して、キャッシュには一つのエントリーしか 存在出来ない。o  最も重要なプログラミングの対象物は、Cache インターフェースである。Cacheへの呼び出しは 、このインターフェースを通じて行われる。
  77. 77. キャッシュの利用 o  データベースからのデータがキャッシュされると よく思われている。もし、JPAを使っているなら、 確かに、そういうことになる。o  ただ、基本的には、作り出すのが高価で時間を 要するものは、なんであれキャッシュに格納出 来る。
  78. 78. キャッシュの利用例 o  データベースの行のキャッシングo  プロセス中のNoSQLデータのキャッシングo  サーブレットのレスポンスのキャッシングo  クライアント側でのWebサービス呼び出しのキャ ッシングo  イメージのレンダー等の高価な計算のキャッシングo  DOMのキャッシング
  79. 79. キャッシュのKey/Value o  KeyとValueに、特別の型の制限はない。o  ただし、KeyとValueは、Nullであってはなら ない。nullキーでのアクセスも、null valueを 設定しようとした場合にも、 NullPointerExceptionが返る。
  80. 80. o  キャッシュは、 storeByValueをサポートしなければ ならない。その意味は、キー/バリューを、オブジェクトで はない表現に変換する方法がなければいけないという ことである。 これは、典型的には、ネットワーク上で送 信出来る、あるいは、永続的なストアに格納出来る、メ モリー外での表現のことを意味する。o  これを達成する一つの方法は、キー/バリューが、 Serializableインターフェースを実装することである。 ただ、実装には他の方法を用いることも出来る。 Serializable以外の方法をサポートするスキームは、 実装依存であり、実装間の移植性を必要とはしない。
  81. 81. キャッシュを見つける o  CacheManagerは、キャッシュを管理する。o  キャッシュは、名前で同定され、アクセスされる。o  キャッシュへの参照は、次のようにgetCache で得られる。Cache cache = cacheManager.getCache(“Greg’s Cache”);
  82. 82. Chapter 3 - Cache Operations
  83. 83. Cache Operations o  Cacheインターフェースは、 ConcurrentMap パターンに基づいている。ただ、それを継承した ものではない。o  というのも、 ConcurrentMap (とMap)のメソ ッドのあるものは、分散環境では、効率的では ないシグニチャーをもつからだ。例えば、 Map.putは、ある値を返すのだが、たいていの 場合、それは無視される。
  84. 84. Cache メソッド o  V get(K key) o  void putAll(Map<?o  Map<K,V> getAll(Set<? extends K,? extends extends K> keys) V> map)o  boolean o  boolean putIfAbsent containsKey(K key) (K key, V value)o  Future<V> load(K key) o  boolean remove(K key)o  Future<Map<K,? extends o  boolean remove  V>> loadAll(Set<? (K key,V oldValue) extends K> keys) o  Vo  CacheStatistics getAndRemove(K key) getStatistics() o  boolean replace(K key,o  void put(K key, V value) V oldValue, V newValue)o  V getAndPut(K key, o  boolean replace(K key,       V value) V value)
  85. 85. Cache メソッド o  V getAndReplace  o  boolean (K key, V value) unregisterCacheEntryLo  void removeAll(Set<? istener(CacheEntryListe extends K> keys) ner<?,?o  void removeAll() > cacheEntryListener)o  CacheConfiguration<K,V o  Object invokeEntryProcessor( > getConfiguration() K key,o  boolean Cache.EntryProcessor<K, registerCacheEntryList V> entryProcessor) ener(CacheEntryListener o  String getName() <? super K,? super V> cacheEntryListener) o  CacheManagero  Iterator<Cache.Entry<K, getCacheManager() V>> iterator() o  <T> T unwrap(Class<T> cls)
  86. 86. Cache Entry Expiration o  キャッシュ中のエントリーは、最終更新時あるいは最終 アクセス時間に基づいて、エクスパイアする。 javax.cache.CacheConfiguration.ExpiryType によってコントロールされる。
  87. 87. Read-Through Caching o  read-through キャッシュは、read-through ではな いキャッシュと全く同じように振る舞う。ただ、エントリー がキャッシュに見つからなかった場合、get()とgetAll( )が、CacheLoaderを呼び出す点が異なる。
  88. 88. Write-Through Caching o  Proxyである。どのような変化も、常に、CacheWriter を呼び出す。o  write-through モードの時、 removeAllNoWriteThroughは、キャッシュのみを全 消去する。 ライター
  89. 89. 参考:eXtreme Scale 後書きキャシング o  後書きキャッシングは、ローダー・プラグインへの更新 情報を 非同期でキューに入れます。eXtreme Scale トランザクションをデータベース・トランザクションから分 離することにより、マップの更新、挿入、 および除去の、 パフォーマンスを改善 できます。非同期更新は、時間ベース の遅延 (例えば、5 分)、 またはエント リー・ベースの遅延 (例えば、1000 エントリー) 後に 実行されます。 http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.extremescale.over.doc%2Fcxswritethr.html
  90. 90. CacheLoader o  CacheLoaderインターフェースは、キャッシュのプリ・ロ ードと、キャッシュミス時の特別なアクションを可能とする 2つの場合に用いられる。o  後者の場合は、例えば、read-throughが実装されて いる場合には、CacheLoaderが利用される。
  91. 91. CacheEntryListener n  CacheEntryCreatedListener n  CacheEntryUpdatedListener n  CacheEntryRemovedListener n  CacheEntryReadListenero  Listenerは、次のいずれかの通知スコープ に登録される。 n  local – このJVMの中でイベントが発生する n  remote – リモートのJVMでイベント発生
  92. 92. Chapter 4 - Cache Managers
  93. 93. Cache Managers o  CacheManagerは、キャッシュの集まりで 、そのコンテナーである。コンテナーとして、 それは、キャッシュのライフサイクルの全て の局面を管理する。
  94. 94. Cache Managersの機能 1.  キャッシュを名前で見つけ出す機能2.  Transactionマネージャにとって、XA Resourceとして 働く。3.  キャッシュのユニットに対して設定の対応をする。4.  自身が起動されると、全ての設定されたキャッシュを起動 する。5.  CacheManagerがシャットダウンされると、その内部の 全てのキャッシュはシャットダウンされる。6.  分散キャッシュのクラスターの統合ポイントである。起動 時には、必要なリソースを割り当て、シャットダウン時には 、それらを解放する。
  95. 95. Cache Managersの機能 7.  デフォールトのキャッシュのテンプレートを提供し、新し いキャッシュが意味のあるデフォールトで作られるよう にする。8.  シングルトンとして、ただ一つのCacheManagerしか 存在しない場合に用いられることもあるし、もっと複雑 なケースでは、VMあたり複数のCacheManagerがも ちられることもある。9.  キャッシュの繰り返しや追加や削除をサポートする。
  96. 96. Construction o  シングルトンのCacheManagerは、次のよ うに構成され、参照される。  CacheManager.getInstance()o  インスタンスの構成 複数のCacheManagerのインスタンスは、 次のようにして生成される。  new CacheManager()
  97. 97. Default CacheManager o  利用を簡単にするために、実装はデフォールトの 設定を提供すべきである。そうすれば、ユーザ によって提供される実装に特有の設定ファイル が無い場合でも、CacheManagerを生成するこ とが出来、キャッシュはそれに追加される。o  Java SEが、この仕様と参照実装を追加して、こ うした機能がJava SE でも利用可能になること が期待されている。 Cache<Integer, Date> myCache2 = cacheManager. <Integer, Date>createCacheBuilder("myCache2"). build();
  98. 98. Cache Configuration Cache<Integer, String> myCache1 = cacheManager. <Integer, String>createCacheBuilder("myCache1"). setCacheLoader(cl). setStoreByValue(true). setReadThrough(true). setWriteThrough(false). setStatisticsEnabled(true). setTransactionEnabled(false). registerCacheEntryListener(listener1,         NotificationScope.LOCAL, false). registerCacheEntryListener(listener2,        NotificationScope.LOCAL, false). build();
  99. 99. simple example String cacheName = "sampleCache"; CacheManager cacheManager = Caching.getCacheManager(); Cache<Integer, Date> cache = cacheManager.getCache(cacheName); if (cache == null) { cache =cacheManager.<Integer,Date>createCacheBuilder(cacheName).build(); } Date value1 = new Date(); Integer key = 1; cache.put(key, value1); Date value2 = cache.get(key);
  100. 100. o  boolean putIfAbsent(K key, V value)if (!cache.containsKey(key)) { cache.put(key, value); return true;} else { return false;}
  101. 101. Interface CacheManager o  <K,V> CacheBuilder<K,V> createCacheBuilder(String cacheName)o  <K,V> Cache<K,V> getCache(String cacheName)o  Iterable<Cache<?,?>> getCaches()o  String getName()o  Status getStatus()o  UserTransaction getUserTransaction()o  boolean isSupported(OptionalFeature optionalFeature)o  boolean removeCache(String cacheName)o  void shutdown()o  <T> T unwrap(Class<T> cls)
  102. 102. Interface CacheBuilder<K,V> o  Cache<K,V> build()o  CacheBuilder<K,V> registerCacheEntryListener(CacheEntryListener<K,V> cacheEntryListener)o  CacheBuilder<K,V> setCacheLoader(CacheLoader<K,? extends V> cacheLoader)o  CacheBuilder<K,V> setCacheWriter(CacheWriter<? super K,? super V> cacheWriter)o  CacheBuilder<K,V> setExpiry(CacheConfiguration.ExpiryType type, CacheConfiguration.Duration duration)o  CacheBuilder<K,V> setReadThrough(boolean readThrough)
  103. 103. Interface CacheBuilder<K,V> o  CacheBuilder<K,V> setStatisticsEnabled(boolean enableStatistics)o  CacheBuilder<K,V> setStoreByValue(boolean storeByValue)o  CacheBuilder<K,V> setTransactionEnabled(IsolationLevel isolationLevel, Mode mode)o  CacheBuilder<K,V> setWriteThrough(boolean writeThrough)
  104. 104. Interface CacheLoader<K,V> o  CacheLoaderは、read-throughキャッシング で利用され、データをキャッシュにロードする。o  Cache.Entry<K,V> load(K key) Loads an object.o  Map<K,V>loadAll(Iterable<? extends K> keys) Loads multiple objects.
  105. 105. Interface CacheWriter<K,V> o  CacheWriterは、 背後にあるリソースへの write-throughキャッシングとwrite-behind キャッシングで利用される。o  void delete(Object key)o  void deleteAll(Collection<?> entries)o  void write(Cache.Entry<K,V> entry)o  void writeAll(Collection<Cache.Entry <? extends K,? extends V>> entries)
  106. 106. Class Caching o  JDKのServiceLoaderのSPI規約を利用して、 CacheManagers を生成する為のFactoryである。o  プロバイダが発見される為に、そのjarファイルは、次の ように、CachingProviderを実装したクラス名のリソー スを含まなければならない。 META-INF/services/ javax.cache.spi.CachingProvider例えば、参照実装では、この中味は次のようになる。"javax.cache.implementation.RIServiceFactory"
  107. 107. Class Caching o  もしも、一つ以上のCachingProviderが見 つかったら、 getCacheManagerFactoryは 、例外を投げる。 o  Cachingクラスはまた、このfactoryで生成さ れた全てのCacheManagersの追跡をする。 getCacheManager()を、再び呼び出した時 には、同じ CacheManagerが返る。
  108. 108. Interface CachingProvider o  CacheManager factory プロバイダによって実装される べきインターフェース。 CacheManagerを生成する為に、 Cachingクラスによって呼び出される。o  このインターフェースの実装は、引数を持たないpublicな コンストラクタを持たなければならない。o  CacheManagerFactory getCacheManagerFactory() Returns the singleton CacheManagerFactory.o  boolean isSupported(OptionalFeature optionalFeature) Indicates whether a optional feature is supported by this implementation
  109. 109. キャッシュは、CacheManagerの中にある o  キャッシュは、キャッシュ・クラスタとの統合のような CacheManager の機能を必要とすることがある ので、CacheManagerの外部で起動されてはな らない。 キャッシュは、まず最初に、追加されねば ならない。o  それらが設定ファイルにあれば、CacheManage rは、起動時に、自動的に追加を行う。動作中の CacheManager に、プログラムを通じてキャッシ ュを追加することも可能である。
  110. 110. Chapter 5 - Transactions
  111. 111. Transactions o  トランザクションは、この仕様のオプショナルな 要件である。トランザクションは、JTA仕様で提 供された意味を持つ。もし、実装されれば、トラ ンザクションはここで規定されたように動作する 必要がある。o  2つのトランザクション・モデルがサポートされ ている。 1.  グローバル・トランザクション:XAトランザクションとし て知られているもの 2.  ローカル・トランザクション:トランザクション境界は、 CacheManager
  112. 112. o  トランザクションを提供する動機は、キャッシュ にとってデータベース、メッセージキュー、その他 のXAリソースと強い整合性を保ち続けることが 、しばしば、非常に重要になるからである。o  トランザクションのサポート無しには、キャッシュ のエントリーは、これらと整合的であるという保 証は出来なくなる。o  あるキャッシュは、ローカルキャッシュか、XAト ランザクションの一つをサポート出来るが、そ の両方を同時にはサポート出来ない。
  113. 113. XA Transactions o  キャッシュのXAトランザクションは、JTAの 仕様と選択された隔離レベルに基づいて機 能する。o  XAトランザクションは、 Transaction Managerの存在を必要とする。o  あるXAトランザクションのコンテキスト外のX Aキャッシュを操作しようと試みると、 CacheExceptionが引き起こされる。
  114. 114. トランザクション・サンプル //Get a global transaction assuming in a// Java EE app serverUserTransaction utxg = jndiContext.lookup(“java:comp/UserTransaction”);// start the transactionsutxg.begin();// do workcache1.put(“key1”, “value”);cache2.remove(“key3”);cache3.put(“key5”, “value4”);// commit the transactionsutxg.commit();
  115. 115. Enlistment o  Enlistmentとは、トランザクション・マネージャが、あるX Aリソースがあるトランザクションに参加しようとしてい ると、それによって告げられるプロセスである。o  javax.transaction.xa パッケージは、トランザクション ・マネージャとリソース・マネージャとの契約を定義して いる。それは、トランザクション・マネージャが、JTAトラ ンザクションにおいて、(リソース・マネージャ・ドライバー によって与えられる)リソース・オブジェクトのリストへの 登録とリストからの削除を可能にする。
  116. 116. o  Enlistmentsは、 TransactionManager.getTransaction().enlistRes ource(XAResource xaRes)を用いることで終了する。o  TransactionManagerへの参照が獲得される方法は、 JTAの仕様では定義されていない。Java EEアプリケ ーション・サーバは、典型的には、参照を取得する為に 、ベンダー固有の、よく知られているJNDIパスを利用し ている。o  XAリソースの最初のオペレーションでは、 TransactionManagerによって、start() が呼ばれる。o  XAは、コネクション指向である。 キャッシュは、コネクシ ョンを信じてはいない。これらは、インピーダンス・ミスマ ッチを生み出す。
  117. 117. o  我々がコネクションを閉じることは無いので、 XAResource.end()が呼びだされることはない。o  我々は、two-phaseコミット・プロトコルがはじまる前に トランザクション・マネージャが、我々の為にend()を呼 び出すことを期待する。(こうしたことは、JTAの仕様では 、全く規定されていないとしても) これが、ほとんど全ての TransactionManagersの振る舞いである。
  118. 118. o  JTAの仕様は次のことを要求している。 「同一のリソースを使って、複数のトランザクション・コン テキストをインターリーブすることは、それぞれのトラン ザクション・コンテキスト・スイッチに対して XAResource.start と XAResource.endが適切に 呼び出される限りで、トランザクション・マネージャによっ て可能となるだろう。リソースが異なるトランザクション で利用されるたびごとに、このリソースが関連づけられ ていた以前のトランザクションに対して、必ず、 XAResource.endメソッドが呼び出され、現在のトラン ザクション・コンテキストに対して、必ず、 XAResource.startが呼び出されなければならない。」
  119. 119. o  もしXAResourceがCacheManagerのレベルにあった とすると、我々は、endを呼び出さないのだから、このこ とは、CacheManagerをまたいでは、同時には、一つ のトランザクションのみが実行可能であることを意味 する。これが、可能な実装である。o  それぞれのトランザクションごとに、ある新しい XAResource が生成されて、一つのキャッシュ・マネ ージャが、トランザクションがあるたびに、沢山の XAResourceをオープンすることが、示唆される。この ようにして、並列トランザクションがサポートされる。イ ンターリービングの問題は、回避される。
  120. 120. o  可能な別の実装は、キャッシュの操作のたびごとに、 XAResourceを生成することである。これは、高い並列 性を実現するが、より多くの、高価なenlistResource() メソッドの呼び出しを要求する。
  121. 121. Recovery o  Cachesは、JTAで定義されている、リカバリー・プロトコ ルを実装しなければならない。特に、 XAResource.recover()は、必ず、サポートしなけれ ばならない。o  永続するストアを持たず、新しいプロセスが空のキャ ッシュで再起動されるような、ローカルなプロセス中 のキャッシュの場合には、recover()が、 javax.transaction.xa.Xid[]の空な配列を返すこと が認められる。o  トランザクション・マネージャは、この場合には、Heuristic Exceptionを報告するかもしれない。
  122. 122. o  このことは、待機中のトランザクションが、他の XAResourcesに対して、正しくリカバーされることを妨 げはしないだろう。さらに、ローカル・キャッシュは、読み 出しのいかなる試みに対しても空なので、影響される値 はキャッシュ・ミスとなり、この値に対するユーザのロジ ックは、影響を受けない。
  123. 123. Local Transactions o  トランザクションをサポートするキャッシュは、4つの隔離 レベルを持つローカル・トランザクションをサポートする だろう。o  ローカル・トランザクションは、トランザクション・マネージ ャの存在を要求しない。o  ローカル・トランザクションは、分散であれローカルで あれ、同一のキャッシュ・マネージャ内の、一つ以上 のキャッシュに対する複数のキャッシュ操作をまたいだ 、シングル・フェーズのコミットを可能とする。
  124. 124. o  このことは、CacheManagerに対する複数の変更を、 全て、単一のトランザクションで適用させることになる。o  もし、データベースのような他のリソースに対して変更を 適用することも望むなら、それらに対するトランザクショ ンを開いて、整合性を保証する為に、手動でコミットとロ ールバックを取り扱う必要がある。(あるいは、XA Transactionsを使用する)o  例えば、キャッシュAに対して2つのputを行い、キャッシュ Bに対して一つのremoveを行い、キャッシュCに対して 4つのputを行うとする。これらは、全て、単一のローカル ・トランザクションの中に納められる。
  125. 125. o  JTA APIは、ローカル・トランザクションのコントロール に使用される。o  javax.transaction.UserTransactionインターフェー スは、アプリケーションにトランザクション境界をプログ ラムでコントロールする能力を与える。
  126. 126. //Get a transactionUserTransaction utx = cacheManager.getUserTransaction();// start a transactionutx.begin();// do workcache1.put(“key1”, “value”);cache2.remove(“key3”);// commit the workutx.commit();
  127. 127. o  全てのローカル・トランザクションに関しての、ベスト・プ ラクティスは、これらのステップを、try-catchブロックの 中に置いて、もし、例外が投げられたら、rollback()を 呼ぶことである。(詳細は、JTAの仕様を参照されたい)o  ローカル・トランザクション・コンテキストの外部からキャ ッシュを操作する試みは、 javax.cache.transaction.TransactionException を引き起こすだろう。
  128. 128. o  単一のスレッドが、XAトランザクションとローカル・トラン ザクションを開始することは可能である。キャッシュ操 作は、トランザクション・コンテキストが存在する故に、X Aならびにローカルなトランザクション・キャッシュの双方 に受け入れられる。しかしながら、トランザクションは分 離している。o  別のプログラム例(EJB言語で、bean managed)、 cache1とcache2はローカル・トランザクションとして設 定され、cache3はXAトランザクションとして設定されて いるは、それを示している。次のようになるだろう。o  ただ、これは動くのだが、一つのトランザクションが成 功し、他のが失敗することもあり得るので、特に、役に 立つという訳でもない。
  129. 129. //Get a local transactionUserTransaction utxl = cacheManager.getUserTransaction();//Get a global transaction assuming in a Java EE app serverUserTransaction utxg = jndiContext.lookup(“java:comp/UserTransaction”);// start the transactionsutxl.begin();utxg.begin();// do workcache1.put(“key1”, “value”);cache2.remove(“key3”);cache3.put(“key5”, “value4”);// commit the transactionsutxl.commit();utxg.commit();
  130. 130. o  ローカル・トランザクションは、すべてCacheException のサブクラスである、自身の例外を持っている。o  TransactionException n  一般的な例外o  TransactionInterruptedException n  キャッシュがトランザクションの処理中に、Thread.interrupt() が呼ばれた時o  TransactionTimeoutException n  トランザクションのタイムアウトが過ぎてから、キャッシュの操作 、あるいは、コミットが呼ばれた場合。
  131. 131. Recovery o  Recoveryは、XAトランザクションに関連している。 Tロ ーカル・トランザクションでは、コミット以前にクラッシュし た場合、変化は、隔離レベルにディペンドする。
  132. 132. Chapter 6 - Isolation Levels
  133. 133. Isolation Levels o  キャッシュの隔離レベルは、生成時に設定され、そ のキャッシュのライフサイクルを通じて、変更不能なまま にとどまる。  隔離レベルには、次の4つがある。o  READ_COMMITTEDo  READ_UNCOMMITTEDo  REPEATABLE_READo  SERIALIZABLEの
  134. 134. READ_COMMITTED o  内容の変化は、COMMIT が呼ばれるまで、ローカル ・キャッシュでも分散キャッシュでも、他のトランザクショ ンには見えない。o  その時まで、次のいずれかの実装が自由である。 n  古いコピーを返す n  コミット、あるいは、ロールバックが呼ばれるまでブロックする。o  両方のアプローチとも、READ_COMMITTED 隔離レ ベルを満たす。
  135. 135. READ_UNCOMMITTED o  キャッシュの変化は、ローカル・キャッシュでも分散キャ ッシュでも、実装上の伝搬の遅延に従いながら、トラン ザクションが利用されなかったように、ただちに他のトラ ンザクションに見える。o  commit時には、値の変化は観測されない。o  rollback時には、値は、以前の値に戻される。これは、 もちろん、目に見える変化だ。o  timeout時には、JTA の仕様は、ロールバックが呼ば れると記述している。だから、timeoutでも、古い値に戻 される。正確にいえば、いつrollbackが起きるかは、実 装依存である。
  136. 136. SERIALIZABLE o  内容の変化は、COMMIT が呼ばれるまで、ローカル ・キャッシュでも分散キャッシュでも、他のトランザクショ ンには見えない。o  さらに、他のトランザクションによって起こされたキャッシ ュの変化は、そのトランザクションが完了するまで、見え ない。o  SERIALIZABLE隔離レベルは、 REPEATABLE_REA Dの上に、Phantom readsからの、さらに進んだ保護 を提供する。
  137. 137. o  An alternative is to exclusively write lock a collection of keys of interest before starting your transaction. We could use lockAll(Collection keys). This would create a ReadWrite lock. Other transactions would block until this transaction.o  This behaviour could be achieved pessimistically with a ReadWrite lock over the entire cache or also achieved optimistically by triggering a RollbackException if any changes made to the keys used (for reads or writes) in this transaction have been made.
  138. 138. REPEATABLE_READ o  Mutating changes are not visible to other transactions in a local cache or a distributed cache until COMMIT has been called.o  Further no changes to the cache made by other transactions for keys once they have or written by this transaction are visible to this transaction until it completes.o  This behaviour could be achieved pessimistically with a ReadWrite lock acquired over the keys as they are used or also achieved optimistically by triggering a RollbackException if any changes made to the keys used (for writes) in this transaction have been made.
  139. 139. Chapter 7 –Caching Annotations
  140. 140. Caching Annotations o  この章では、Java Caching 1.0 仕様で定義された、 アノテーションについて議論する。アノテーションは、こ の仕様のオプショナルな部分であり、独立したライブ ラリーとしても実装可能である。o  アノテーション・クラスのJavaDocは、機能の詳細な記 述として読まれるべきである。
  141. 141. Annotations Overview o  アノテーションとそのサポートクラスは、 javax.cache.annotationパッケージに ある。
  142. 142. Annotation Inheritance andOrdering o  この仕様は、アノテーションの継承について、Java仕様の Common Annotations の2,1節に従っている。o  この仕様外のアノテーションに関する、インターセプター の実行の順序については定義されておらず、アノテーシ ョンをサポートする実装に委ねられている。
  143. 143. Multiple Annotations o  一つのメソッドには、一つのメソッド・レベルのキャッシ ング・アノテーションのみが指定でき、パラメータでは、 一つのパラメータ・レベルのアノテーションのみが指定 出来る。o  もし、一つ以上のアノテーションが、メソッドないしはパ ラメータに指定された場合には、アプリの初期化時、あ るいは、メソッドの呼び出し時に、 CacheAnnotationConfigurationException が投 げられねばならない。
  144. 144. @CacheDefaults o  @CacheDefaultsは、クラス内で利用されるキャッシン グに関連した全てのアノテーションのデフォールトのプ ロパティの値を定義するのに用いられる、クラス・レベル のアノテーションである。o  cacheName, cacheResolverFactory, cacheKeyGeneratorといったプロパティが指定される 。ただし、全て、オプショナルである。o  もし、@CacheDefaultsがクラスに指定されて、メソッド ・レベルのキャッシング・アノテーションが存在しない場合、 @CacheDefaultsアノテーションは無視される。
  145. 145. o  次の例は、このクラスのキャッシュのデフォールトとして 利用される、”cities”という名前のキャッシュを指定して いる。o  getCityメソッドの、@CacheResultアノテーションは、 実行時にこのキャッシュの名前を利用する。 @CacheDefaults(cacheName=”cities”) public class CitySource { @CacheResult public City getCity(int lat, int lon) { //... } }
  146. 146. package my.app;@CacheDefaults(cacheName="domainCache")public class DomainDao { @CacheResult public Domain getDomain(String domainId, int index) { ... } @CacheRemoveEntry public void deleteDomain(String domainId, int index) { ... } @CacheResult(cacheName="allDomains") public List<Domain> getAllDomains() { ... }}
  147. 147. @CacheResult o  @CacheResultは、メソッド・レベルのアノテーションで ある。その返り値がキャッシュされることを、メソッドにマ ークする為に用いられる。この時、キーは、メソッド・パ ラメータから生成され、同一のパラメータでのその後の 呼び出しでキャッシュは、このキーを返す。o  @CacheKeyParam アノテーションは、キーの生成に おいて、パラメータのサブセットを選択するのに利用され うる。
  148. 148. o  オプション 1.  cacheNullプロパティを通じて、返り値nullのキャッシュをコン トロールする 2.  オプショナルなキャッシングと名前を持つキャッシュ自身の例外 の再発行。キャッシュ固有の例外の機能を含む。 3.  Cacheが呼ばれた時、オプションで、事前実行をスキップする。 アノテーションをつけられたメソッドが、常に実行され、返り値 がキャッシュにおけれるべき時には役に立つ。o  @CacheResult は、staticなメソッドに置かれた場合 には、無視される。
  149. 149. package my.app;public class DomainDao { @CacheResult public Domain getDomain(String domainId, int index) { ... }} package my.app;public class DomainDao { @CacheResult public Domain getDomain(@CacheKey String domainId, Monitormon) { ... }}
  150. 150. @CachePut o  @CachePutは、メソッド・レベルのアノテーションで、そ のメソッドの引数の一つがキャッシュに格納されるべきこ とをマークする。一つの引数は、それがキャッシュされ るべきことを示す為に、@CacheValue アノテーション でマークされねばならない。o  もし、@CacheValueアノテーションが指定されなけ れば、アプリの初期化時あるいはメソッドの呼び出し時に CacheAnnotationConfigurationExceptionが投げ られねばならない。o  @CacheKeyParam アノテーションは、キー生成時に パラメータのサブセットを選択するのに用いられるが、 @CacheValueアノテーションのパラメータは、キー生 成に含まれることは無い。
  151. 151. o  オプション 1.  cacheNullプロパティを通じて、返り値nullのキャッシュをコン トロールする 2.  Cache.putの呼び出しが、このメソッドの実行以前、あるいは 実行後に起きるのかを指定する。 3.  呼び出しの後に、キャッシングが起きれば、アノテートされたメソ ッドからの例外は、Cache.put呼び出しをキャンセル出来る。o  @CachePutは、staticなメソッドに置かれた場合には 、無視される。
  152. 152. @CachPutでアノテートされたメソッドが呼び出された時、CachKeyが生成され、指定されたキャッシュ上でCache.put(Object, Object)が呼び出され、@CacheValueでマークされた値を、キャッシュに格納する。Null値は、デフォールトではキャッシュされるが、この振る舞いは、cacheNull()プロパティで、無効にできる。package my.app;public class DomainDao { @CachePut(cacheName="domainCache") public void updateDomain(String domainId, int index, @CacheValue Domain domain) { ... }}
  153. 153. @CacheRemoveEntry o  @CacheRemoveEntryは、メソッド・レベルのアノテーシ ョンで、エントリー中のメソッドの呼び出しの結果が指定さ れたキャッシュで削除されることをマークする。o  @CacheKeyParam アノテーションは、キーの生成にお いて、パラメータのサブセットを選択するのに利用される。o  オプション 1.  Cache.removeの呼び出しが、このメソッドの実行以前、あるい は実行後に起きるのかを指定する。 2.  呼び出し後に削除が起きれば、アノテートされたメソッドによって 投げられた例外は、Cache.remove呼び出しをキャンセルできる。o  @CacheRemoveEntryは、staticなメソッドに置かれ た場合には、無視される。
  154. 154. package my.app;public class DomainDao { @CacheRemoveEntry(cacheName="domainCache") public void deleteDomain(String domainId, int index) { ... }}
  155. 155. @CacheRemoveAll o  @CacheRemoveAllは、メソッド・レベルのアノテーショ ンで、メソッドの呼び出しの結果のエントリー全てが、指 定されたキャッシュで削除されることをマークする。o  オプション 1.  Cache.removeAllの呼び出しが、このメソッドの実行以前、あ るいは実行後に起きるのかを指定する。 2.  呼び出し後に削除が起きれば、アノテートされたメソッドによっ て投げられた例外は、Cache.removeAll呼び出しをキャンセ ルできる。o  @CacheRemoveAllは、staticなメソッドに置かれた 場合には、無視される。
  156. 156. デフォールトの振る舞いでは、アノテートされたメソッドが呼び出された後に、Cache.removeAll()が呼ばれる。この振る舞いは、afterInvocation() をfalseにすることで変更出来る。この場合、Cache.removeAll()は、アノテートされたメソッドが呼び出される前に呼ばれる。package my.app;public class DomainDao { @CacheRemoveAll(cacheName="domainCache") public void deleteAllDomains() { ... }}
  157. 157. @CacheKeyParam o  @CacheKeyParamは、パラメータ・レベルのアノテ ーションで、パラメータがCacheKeyGeneratorを通じて CachKeyを生成するのに利用されることをマークする。o  実行時、@CacheKeyParamでアノテートされたパラメ ータは、 CacheKeyInvocationContext.getKeyParameters () アレーの中に置かれる。.o  @CacheResult, @CachePut, @CacheRemoveEntryと一緒に使うことは出来ない。
  158. 158. @CacheValue o  @CacheValueは、パラメータ・レベルのアノテーショ ンで、@CachePutでアノテートされたメソッドの、キャ ッシュされるべきパラメータをマークするのに用いられる。 @CachePutでアノテートされたパラメータは、 CacheKeyInvocationContext.getKeyParameters () アレーに含まれてはいけない。.o  @CachePutと一緒に用いられる。
  159. 159. Cache Resolution o  メソッド・レベルのアノテーションは、全て、 CacheResolverFactory の仕様とキャッシュを決定す る為に用いられるキャッシュの名前が、実行時に相互 に作用することを可能にする。
  160. 160. Cache Name o  もし、キャッシュの名前が、メソッド・レベルのアノテーシ ョンでも、@CacheDefaults アノテーションでも指定さ れていなければ、名前は、次のように生成される。o  package.name.ClassName.methodName(packa ge.ParameterType,package.ParameterType)o  @CacheResultは、追加的に、 exceptionCacheNameプロパティを持っている。もし 、この名前が指定されていなければ、デフォールトの例 外キャッシュ名も例外キャッシュも利用されない。
  161. 161. CacheResolverFactory o  指定されたCacheResolverFactoryは、 毎回のアノテー トされたメソッドの呼び出しのたびに利用される CacheResolverを決定する為に、アノテートされたメソッ ドについて、正確に、一回呼ばれねばならない。o  アノテートされたメソッドが実行されると、以前に取得された CacheResolverが、CacheInvocationContextに基 づいて利用すべきキャッシュを決定する為に用いられる。o  javax.cache.annotation.CacheResolverFactory がアノテーションと@CacheDefaultsで指定されると、 デフォールトのCacheResolverFactory のロジックが利 用される。
  162. 162. o  デフォールトの CacheResolverFactoryのルール: 1.  Caching.getCacheManager()を通じて、利用する CacheManager を取得する。 2.  キャッシュの名前で、CacheManager.get(String)を呼ぶ。 3.  Cacheが返らなかったら、CacheManager.createCacheBuilder を使って、キャッシュを生成する。 4.  見つかった/生成されたキャッシュをラップし、常にキャッシュを返 すCacheResolverを生成する。o  もし、CacheResolverFactoryが例外を投げたら、そ の例外は、CacheResolverFactoryの実行をトリガー したアプリケーション・コードまで、伝搬されねばならない。
  163. 163. CacheResolver o  CacheResolverは、CacheResolver ファクトリーによ って返えされる。このことは、それが返されるアノテート された全てのメソッドの呼び出しのたびに、 呼び出され 、この呼び出しに利用されるキャッシュを返す。o  もし、CacheResolverが例外を投げたら、その例外は、 CacheResolverの実行をトリガーしたアプリケーション ・コードまで、伝搬されねばならない。
  164. 164. Key Generation o  @CacheResult, @CachePut, @CacheRemoveEntryアノテーションは、全て、キャ ッシュ・キーが生成されることを要求する。これらのア ノテーションの全ては、 CacheKeyGeneratorの実装 の仕様に従う。o  指定されたCacheKeyGeneratorは、アノテートされた メソッドの呼び出しのたびに、一回だけ呼ばれる。アノテ ートされたメソッドと現在の呼び出しの情報は、 CacheKeyInvocationContextによって与えられる。
  165. 165. o  開発者がキーで利用されるように指定した、メソッドのパ ラメータは、getKeyParameters() メソッドで返される CacheInvocationParameterアレーに含まれる。カス タムのCacheKeyGenerator は、CacheKeyを生成 する為に、それが利用可能ないかなる情報も利用出 来る。o  もしjavax.cache.annotation.CacheKeyGenerator  と@CacheDefaultsがアノテーションに指定されれば 、デフォールトのCacheKeyGeneratorが利用されね ばならない。
  166. 166. o  デフォールトのCacheKeyGeneratorのルール: 1.  CacheKeyInvocationContext.getKeyParameters()で 返されたアレーから、 CacheInvocationParameter.getValue() を使って、 Object[]を生成する。 2.  Object[]をラップしたCacheKeyインスタンスを生成する。 Arrays.deepHashCodeを使ってそのhashCodeを計算し、 Arrays.deepEqualsを使って、他のキーとの比較を行う。o  もし、CacheKeyGeneratorが例外を投げたら、その 例外は、CacheKeyGeneratorの実行をトリガーした アプリケーション・コードまで、伝搬されねばならない。
  167. 167. Annotation Support Classes o  CacheMethodDetails n  キャッシング・アノテーションを持つメソッドについての、Static な情報。実行時に、CacheResolverFactory によって、 CacheResolver を決定する為に利用される。o  CacheInvocationContext n  キャッシング・アノテーションを持つメソッドの実行についての実 行時の情報。CacheResolver によって、利用すべきキャッシ ュを決定するのに利用される。CacheMethodDetails を継承 した、全てのstaticな情報が利用可能である。
  168. 168. o  CacheKeyInvocationContext n  @CacheResult, @CachePut, @CacheRemoveEntryの いずれかでアノテートされた、キー生成が行われるメソッドの実 行に関する実行時の情報。CacheKeyGenerator によって、 CacheKey を生成する為に利用される。 CacheInvocationContext を継承した、全ての実行時ある いは、staticな情報が利用可能である。o  CacheInvocationParameter n  メソッドの実行のパラメータについての実行時の情報。パラメ ータ・アノテーション、その位置、型、値が含まれる。 CacheInvocationContextとCacheKeyInvocationContex tによって与えられる。
  169. 169. o  CacheKey n  CacheKeyGeneratorインターフェースによって生成される。 CacheKey は、アノテーションによって相互作用する全て のキャッシュのキーとして利用される。全てのCacheKey は、 複製不可でかつserializable出なければならない。
  170. 170. Chapter 8 - Container andProvider Contracts for Deploymentand Bootstrapping
  171. 171. Container and Provider Contracts forDeployment and Bootstrapping o  Java SEの環境では、 CacheManagerFactory.getCacheManagerメソッ ドは、新しいCacheManagerの生成を要求することが ある。その為に、 javax.cache.CacheManager.CacheManagerFact oryProvider インターフェースのインスタンスを位置づ ける。o  Java SEの環境で走るキャッシュ・プロバイダーの実 装は、JARファイルの仕様で記述されたサービス・プロ バイダの設定ファイルを備えた、サービス・プロバイダと しても動作すべきである。
  172. 172. o  プロバイダーの設定ファイルは、プロバイダの実装クラ スを、そのプロバイダをキャッシュ・マネージャのファク トリーとして位置づけて、CacheManagerFactory ブ ートストラップ・クラスに、エキスポートする役割をはたす。o  The provider supplies the provider configuration file by creating a text file named javax.cache.spi.CacheManagerFactoryProvider and placing it in the META-INF/services directory of one of its JAR files. The contents of the file should be the name of the provider implementation class of the javax.cache.CacheManager.CacheManagerFact oryProvider interface.
  173. 173. o  Example:o  A persistence vendor called ACME caching products ships a JAR called acme.jar that contains its cache provider implementation. The JAR includes the provider configuration file. acme.jarMETA-INF/services/javax.cache.spi.CacheManagerFactoryProvidercom/acme/cache/CacheManagerFactoryProvider.class...
  174. 174. o  The contents of the META-INF/services/ javax.cache.spi.CacheManagerFactoryProvider file is nothing more than the name of the implementation class: com.acme.cache.CacheManagerFactoryProvidero  Cache provider jars may be installed or made available in the same ways as other service providers, e.g. as extensions or added to the application classpath according to the guidelines in the JAR File Specification.
  175. 175. o  If more than one provider jar is registered the first one found by java.util.ServiceLoader will be used. If no provider is found, CacheManagerFactory.getCacheManager will thow an IllegalStateException.
  176. 176. Use of Caching o  The API provides a static means of accessing caching support through the class javax.class.Caching.o  Examples include // get the default cache managerCacheManager defaultCacheManager = Caching.getCacheManager();// the default cache manager can also be fetched by name assertdefaultCacheManager ==Caching.getCacheManager(javax.cache.Caching.DEFAULT_CACHE_MANAGER_NAME);//Can get a non default named CacheManagerCacheManager myCacheManager =Caching.getCacheManager("MyManager");
  177. 177. Chapter 9 - Glossary
  178. 178. o  CacheManager A container for caches, which holds references to them.o  Cache A collection of related items.o  Caching Unit A logical grouping under the control of a CacheManagero  Key A way of unambiguously identifying a unique item in a Cache.o  Value The value stored in a Cache. Any Java Object can be a value.o  CacheLoader A user-defined Class which is used to load key/value pairs into a Cache on demand.
  179. 179. o  CacheWriter A user-defined Class which is used to write key/value pairs into a cache after a put operation.o  Cache Store A place where cache data is kept. Caches may have multiple stores.o  CacheEventListener A user-defined Class which listens to Cache events.o  Eviction Policy Method by which elements are evicted from the cache. E.g. FIFO, LFU, …
  180. 180. Resin 4.0 jcache(distributed caching)
  181. 181. public class MyServlet extends GenericServlet { @Current Cache _cache; public void service(ServletRequest req, ServletResponse res) { PrintWriter out = res.getWriter(); String data = (String) _cache.get("my-data"); if (data != null) { out.println("cached data: " + data); } else { data = generateComplicatedData(); _cache.put("my-data", data); out.println("new data: " + data); } }} http://www.facebook.com/note.php?note_id=58113794812
  182. 182. <web-app xmlns="http://caucho.com/ns/resin" xmlns:cluster="urn:java:com.caucho.cluster"> <cluster:ClusterCache name="comment-cache"/></web-app>
  183. 183. Maven Snippet <dependency> <groupId>javax.cache</groupId> <artifactId>cache-api</artifactId> <version>0.3</version></dependency>
  184. 184. Creating a CacheManagerCacheManager cacheManager = Caching.getCacheManager();CacheManager cacheManager = Caching.getCacheManager(“app1”,      Thread.currentThread().getContextClassLoader());CacheManager cacheManager = new RICacheManager(“app1”,      Thread.currentThread().getContextClassLoader());String className = "javax.cache.implementation.RIServiceProvider";Class<ServiceProvider> clazz      =(Class<ServiceProvider>)Class.forName(className);ServiceProvider provider = clazz.newInstance();return provider.createCacheManager(Thread.currentThread().getContextClassLoader(), "app1");
  185. 185. o  We expect implementations to have their own well-known configuration files which will be used to configure the CacheManager.o  The name of the CacheManager can be used to distinguish the configuration file.o  For ehcache, this will be the familiar ehcache.xml placed at the root of the classpath with a hyphenated prefix for the name of the CacheManager. So, the default CacheManager will simply be ehcache.xml and “myCacheManager” will be app1-ehcache.xml.
  186. 186. Creating a CachecacheManager = getCacheManager();CacheConfiguration cacheConfiguration =   cacheManager.createCacheConfiguration()cacheConfiguration.setReadThrough(true);Cache testCache =   cacheManager.createCacheBuilder(“testCache”)    .setCacheConfiguration(cacheConfiguration).build();
  187. 187. Getting a reference to a Cache o  You get caches from the CacheManager. To get a cache called “testCache”:Cache<Integer, Date> cache =    cacheManager.getCache(“testCache”);
  188. 188. Basic Cache Operations o  To put to a cache:Cache<Integer, Date> cache =   cacheManager.getCache(cacheName); Date value1 = new Date(); Integer key = 1; cache.put(key, value1);o  To get from a cache:Cache<Integer, Date> cache = cacheManager.getCache(cacheName); Date value2 = cache.get(key);
  189. 189. o  To remove from a cache:Cache<Integer, Date> cache = cacheManager.getCache(cacheName); Integer key = 1; cache.remove(key);
  190. 190. Annotations o  The JSR107 annotations cover the most common cache operations including: n  @CacheResult – use the cache n  @CachePut – put into the cache n  @CacheRemoveEntry – remove a single entry from the cache n  @CacheRemoveAll – remove all entries from the cache
  191. 191. public class DomainDao { @CachePut(cacheName="domainCache") public void updateDomain(String domainId, @CacheKeyParam int index, @CacheValue Domain domain) { ... }}
  192. 192. Annotation Example public class BlogManager {@CacheResult(cacheName="blogManager")public Blog getBlogEntry(String title) {...}@CacheRemoveEntry(cacheName="blogManager")public void removeBlogEntry(String title) {...}@CacheRemoveAll(cacheName="blogManager")public void removeAllBlogs() {...}@CachePut(cacheName=”blogManager”)public void createEntry(@CacheKeyParam String title,@CacheValue Blog blog) {...}@CacheResult(cacheName="blogManager")public Blog getEntryCached(String randomArg,@CacheKeyParam String title){...}}
  193. 193. Wiring Up Spring <jcache-spring:annotation-driven proxy-target-class="true"/>A full example is:<beans ...> <context:annotation-config/> <jcache-spring:annotation-driven proxy-target-class="true"/> <bean id="cacheManager" factory-method="getCacheManager" /></beans>
  194. 194. Wiring Up CDI o  First create an implementation of javax.cache.annotation.BeanProvider and then tell CDI where to find it declaring a resource named javax.cache.annotation.BeanProvider in the classpath at /META-INF/services/.o  For an example using the Weld implementation of CDI, see the CdiBeanProvider in our CDI test harness.
  195. 195. Resin 4.0 jcache (distributed caching) public class MyServlet extends GenericServlet { @Current Cache _cache; public void service(ServletRequest req, ServletResponse res) { PrintWriter out = res.getWriter(); String data = (String) _cache.get("my-data"); if (data != null) { out.println("cached data: " + data); } else { data = generateComplicatedData(); _cache.put("my-data", data); out.println("new data: " + data); } }}
  196. 196. configuration <web-app xmlns="http://caucho.com/ns/resin" xmlns:cluster="urn:java:com.caucho.cluster"> <cluster:ClusterCache name="comment-cache"/></web-app>

×