{"_id":"569f3e578f6d4b0d00f13bd5","__v":9,"user":"55e84e0f0693802d00bc6952","category":{"_id":"568a404e050eb50d00c07999","__v":7,"pages":["568a404f050eb50d00c0799b","5698f130cb127f0d003cc06a","5698f1483da4370d009d2079","569e6013d233620d00705550","569f3e578f6d4b0d00f13bd5","56a9d3d43b04f20d00eccaa5","56cc2b9e94c8f00b00b83d76"],"project":"568a404d050eb50d00c07995","version":"568a404e050eb50d00c07998","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-04T09:50:06.816Z","from_sync":false,"order":9999,"slug":"documentation","title":"Documentation"},"project":"568a404d050eb50d00c07995","version":{"_id":"568a404e050eb50d00c07998","project":"568a404d050eb50d00c07995","__v":2,"createdAt":"2016-01-04T09:50:06.218Z","releaseDate":"2016-01-04T09:50:06.218Z","categories":["568a404e050eb50d00c07999","56cc2b81272aa4130002cce9"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-01-20T07:59:19.683Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":3,"body":"BlazingCache uses the JCache (JSR107) https://jcp.org/en/jsr/detail?id=107 interface in order to provide an unified API for cache clients.\nThis page will describe the details of how BlazingCache implements JSR107.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Maven Dependency\"\n}\n[/block]\nIn order to use the JSR107 you need an additional dependency:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<dependency>\\n   <groupId>org.blazingcache</groupId>\\n   <artifactId>blazingcache-jcache</artifactId>\\n   <version>VERSION</version>\\n</dependency>\",\n      \"language\": \"xml\"\n    }\n  ]\n}\n[/block]\nUsing this dependency the javax.cache.Caching.getCachingProvider() will give you the BlazingCache based implementation. In case of presence of more than one implementation you have to discover available providers or instantiate directly BlazingCacheProvider.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"CacheManager and CacheClient\"\n}\n[/block]\nEach CacheManager will instantiate a CacheClient and so it will handle the connectivity to the CacheServer. For each javax.cache.Cache the CacheManager will provide an abstraction on the key space and will use the name of the javax.cache.Cache as a prefix for keys.\n\nBe sure to **close** the CacheManager, which in turn will shutdown the CacheClient, closing network connections and stopping all the support threads.\nClosing the BlazingCacheProvider will close of the CacheManager.\nClosing a javax.cache.Cache will not close the underlying CacheClient.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Serialization\"\n}\n[/block]\nBlazingCache has been built to manage keys as Strings and values as byte[] but when using the javax.cache.Cache API you can use any java.io.Serializable class for your application.\nYour keys will be converted automatically to String using the KeySerializer.\n\nYou can configure the KeySerializer using the \"blazingcache.jcache.keyserializer\" property when getting the CacheManager.  If you are going to use String keys the default serializer will use them directly, only prepending them with the suffix.\nYour values will be converted automatically to byte[] using the ValuesSerializer. You can configure the ValuesSerializer using the \"blazingcache.jcache.valuesserializer\" property when getting the CacheManager. The default is ValuesSerializer.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Listeners, Cache integrations and ExpiryPolicies\"\n}\n[/block]\nEvery configurable artifact passed to the CacheManager.createCache will be instantiated and executed by the local JVM. You have to configure every client in the same way in order to achieve a uniform behavior for your CacheLoader, CacheWriter, Listener and ExpiryPolicy. \nActually asynchronous listeners are executed in the same thread (and so they are not really asynchronous).\n\nWhen you configure Listeners or CacheLoaders or CacheWriters some times the specs require the system to access the 'previous value' and this will lead to issuing fetchs or other network-related operations.\nThen you configure expiration by access every get will need a *touch* in order to change the expiration timestamp for the entry.\nThe default configuration, without such artifacts will use the best of BlazingCache and achieve the maximum performance.\n\nA note on statistics: the \"average times\" are never computed and will always return 0. Other kind of statistics will be very accurate.\n\nWarning: CAS-operations are not working properly in version 1.3.0 or below, they are only prototypes which does not enforce concurrency requirements. Same applies to EntryProcessor operations.\n\nSince version 1.4.0 CAS semantics are working as expected","excerpt":"","slug":"jcache-jsr107-client","type":"basic","title":"JCache (JSR107) Client"}

JCache (JSR107) Client


BlazingCache uses the JCache (JSR107) https://jcp.org/en/jsr/detail?id=107 interface in order to provide an unified API for cache clients. This page will describe the details of how BlazingCache implements JSR107. [block:api-header] { "type": "basic", "title": "Maven Dependency" } [/block] In order to use the JSR107 you need an additional dependency: [block:code] { "codes": [ { "code": "<dependency>\n <groupId>org.blazingcache</groupId>\n <artifactId>blazingcache-jcache</artifactId>\n <version>VERSION</version>\n</dependency>", "language": "xml" } ] } [/block] Using this dependency the javax.cache.Caching.getCachingProvider() will give you the BlazingCache based implementation. In case of presence of more than one implementation you have to discover available providers or instantiate directly BlazingCacheProvider. [block:api-header] { "type": "basic", "title": "CacheManager and CacheClient" } [/block] Each CacheManager will instantiate a CacheClient and so it will handle the connectivity to the CacheServer. For each javax.cache.Cache the CacheManager will provide an abstraction on the key space and will use the name of the javax.cache.Cache as a prefix for keys. Be sure to **close** the CacheManager, which in turn will shutdown the CacheClient, closing network connections and stopping all the support threads. Closing the BlazingCacheProvider will close of the CacheManager. Closing a javax.cache.Cache will not close the underlying CacheClient. [block:api-header] { "type": "basic", "title": "Serialization" } [/block] BlazingCache has been built to manage keys as Strings and values as byte[] but when using the javax.cache.Cache API you can use any java.io.Serializable class for your application. Your keys will be converted automatically to String using the KeySerializer. You can configure the KeySerializer using the "blazingcache.jcache.keyserializer" property when getting the CacheManager. If you are going to use String keys the default serializer will use them directly, only prepending them with the suffix. Your values will be converted automatically to byte[] using the ValuesSerializer. You can configure the ValuesSerializer using the "blazingcache.jcache.valuesserializer" property when getting the CacheManager. The default is ValuesSerializer. [block:api-header] { "type": "basic", "title": "Listeners, Cache integrations and ExpiryPolicies" } [/block] Every configurable artifact passed to the CacheManager.createCache will be instantiated and executed by the local JVM. You have to configure every client in the same way in order to achieve a uniform behavior for your CacheLoader, CacheWriter, Listener and ExpiryPolicy. Actually asynchronous listeners are executed in the same thread (and so they are not really asynchronous). When you configure Listeners or CacheLoaders or CacheWriters some times the specs require the system to access the 'previous value' and this will lead to issuing fetchs or other network-related operations. Then you configure expiration by access every get will need a *touch* in order to change the expiration timestamp for the entry. The default configuration, without such artifacts will use the best of BlazingCache and achieve the maximum performance. A note on statistics: the "average times" are never computed and will always return 0. Other kind of statistics will be very accurate. Warning: CAS-operations are not working properly in version 1.3.0 or below, they are only prototypes which does not enforce concurrency requirements. Same applies to EntryProcessor operations. Since version 1.4.0 CAS semantics are working as expected