 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 107: JCACHE - Java Temporary Caching API
List of JCACHE compatible implementations The following updates have been made to the original proposal on the dates shown.
2019.02.01:
2017.10.20: Name: Joe Fialli
e-mail address: joe.fialli telephone number: +1 781-442-0795
2013.03.05: Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
The JSR moved to JCP 2.9. 2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.There are two channels for feedback. First is via the JSR 107 forum. Secondly is via raising issues in the Issue Tracker.
2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?https://github.com/jsr107/jsr107spec/issues 2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.For specification documentation: https://docs.google.com/document/d/1YZ-lrH6nW871Vd9Z34Og_EqbX_kxxJi55UrSn4yL2Ak/edit?hl=en_US
2012.10.23: Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Note that this information has been updated since this update. Final Specification license
2012.04.20: Specification Leads: Brian Oliver (Oracle), Cameron Purdy (Oracle), Greg Luck E-Mail Addresses: brian.oliver Telephone Numbers: +1 781 640 6842, +1 781 442 0145, +61 7 3368 2122 Fax Numbers: -, -, -
2011.07.25:
2011.05.04:
2007.05.15:
2003.12.19: Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Submitting Member:Oracle Corporation Name of Contact Person: E-Mail Address: Telephone Number: Fax Number: Specification Lead: E-Mail Address: Telephone Number: Fax Number: Note that the above information has been updated from this original proposal. Initial Expert Group Membership:
Jerry Bortvedt, Oracle Corporation
Section 2: Request
2.1 Please describe the proposed Specification:Caching is a tried and true method for dramatically speeding up applications. Applications often use temporary data which are expensive to create, but have a lifetime over which they can be reused. For example, a servlet might create a web page from data obtained from multiple databases, network connections, and expensive computations; the sets of data might be reusable over the same or different periods of time. The JCACHE specification standardizes in process caching of Java objects in a way that allows an efficient implementation, and removes from the programmer the burden of implementing cache expiration, mutual exclusion, spooling, and cache consistency. Objects whose type is not known until runtime can be cached, but only those which implement the serializable interface can be spooled. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Can be used on any Java platform. Particularly useful on server platforms, such as a servlet container. 2.3 What need of the Java community will be addressed by the proposed specification?What need of the Java community will be addressed by the proposed specification? The primary goal of JCACHE is to allow developers to write as little code as possible to solve a very common problem. 2.4 Why isn't this need met by existing specifications?There are no existing specifications which deal with automatic creation and refresh of temporary, in-process data shared across threads. JNDI provides an interface for looking up objects by name, and an interface (the SPI) which could be used for a caching implementation. However, the application would be required to check expiration of retrieved objects after each look up, and sychronize creation and binding of a new object. Per object cache attributes (e.g., expiration time) would require introduction of an additional level of indirection: the application would look up a cache handle and use one of its methods to access the associated object. java.util.Hashtable provides a way of looking up cached objects by name, but has no way to materialize objects in the cache without application enforcement of expiration and mutual exclusion. The granularity of Hashtable locking is the whole table, which affects application scalability when multiple threads access the HashTable. HashTable also has no underlying spooling capability. JavaSpaces and Enity Enterprise Java Beans deal with caching of persistent, transactional data. Cached data do not always come from data stores; they may be the result of an expensive computation or a remote procedure call. Also, these interfaces do not deal with efficient handling of expiration and refresh of cached data. Enterprise Java Beans are designed primarily for remote access to objects. Although an in-process implementation of EJB is possible, the application code would still have to make all of the additional calls required for remote object access. EJB's must be pre-defined by the application, and do not have any concept of shared access or expiration. javax.servlet.http.HttpSession allows named objects of arbitrary type to be cached, but does not have the concept of sharing, invalidation, per object expiration, automatic loading, or spooling. 2.5 Please give a short description of the underlying technology or technologies:An application begins by creating a cache name space and associating a cache loader with it. The cache loader is application code which materializes application objects to be cached. Following this simple initialization, concurrent threads may retrieve objects from the cache. If the object does not exist or has expired, the cache loader is invoked. When the cache meets it memory limit, its replacement policy decides which objects should be spooled to disk and when. An application may optionally associate a set of attributes with a name space or with individual cached objects. Examples of attributes are time to live, expiration date, and whether an object can be spooled. Applications may also explicitly create, replace, remove, or invalidate objects in the cache. Using a cache event listener, the application may interpose before cache actions whether invoked by the cache system or explicitly by the application. Changes to the cached objects may be sychronized across multiple JVM's on multiple hosts. However, the application designer must carefully weigh the advantages of the performance cost against the functionality gain. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.util.jcache in j2ee (although it could be useful in j2se) 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No. 2.8 Are there any security issues that cannot be addressed by the current security model?No. 2.9 Are there any internationalization or localization issues?No. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. 2.11 Please describe the anticipated schedule for the development of this specification.
Note that this JSR has been updated since this original proposal.
Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Functional Specification for Object Caching Service for Java (OCS4J), 2.0 3.2 Explanation of how these items might be used as a starting point for the work.Basic functionality is described. However, the documented API excludes spooling and includes extraneous functionality such as pooling which would probably not be included in JCACHE. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.This section contains any additional information that the submitting Member wishes to include in the JSR. The Oracle Java caching system has been in use internally in Oracle products for about 2 years. It has proved to be popular among developers. |
