JCS is not entirely JCache compliant. There were licensing issues and the specification is not set in stone, so JCS was built how we saw best. It does not implement object ownership. I discuss other differences on the web site.
http://jakarta.apache.org/turbine/jcs/JCSandJCACHE.html (Just a note, but JCS has far more features and is far more flexible than any pure JCache compliant cache. JCS is very plugable: You can change the memory management algorithm, you can plugin another local disk cache, you can choose between 3 kinds of lateral distribution mechanisms, or you can use a centralized remote cache. It is also highly configurable, down to the way each individual element is managed.) As does JCS, All JCache compliant caches give you a reference to the object. (They should also implement a locking mechanism, which JCS does not. Locking is to solve a different problem involving managing the order in the distributed caches. Distributed locking would be slow, highly unreliable, and would present all sorts of blocking situations so we didn't try it yet.) All JCache compliant caches have the same issue we have been discussing. >From the JCache API: http://jcp.org/aboutJava/communityprocess/jsr/cacheFS.pdf 4. Object get(Object name) throws ObjectNotFoundException, NotARetrievableObjectException, InvalidHandleException Object get(Object name, Object args) throws ObjectNotFoundException, NotARetrievableObjectException, InvalidHandleException Object get(Object name, String group, Object args) throws ObjectNotFoundException, InvalidGroupException, NotARetrievableObjectException, InvalidHandleException Get returns a reference to the object associated with name. If the object is a streamAccess object, an InputStream is returned, if the object is a disk object a String containing the full path to the object is returned. The name object must override the Object.equals and Object.hashCode methods. If the object is not currently in the cache and a loader object has been registered, the object will be loaded into the cache passing the args parameter to the load method of the loader object. If a loader object has not been registered for the object the default load method will do a netSearch for the object. If a group is specified and the object is loaded, it will be associated with the group. The object returned by get is always a reference to a shared object. Get will always return the latest version of the object. A CacheAccess object will only maintain a reference to one cached object at any given time. If get is called multiple times, the object accessed previously, will be released. If the object is not found in the cache, an ObjectNotFoundException is thrown. If the group is specified but doesn't exist an InvalidGroupException will be thrown. If name refers to a group a NotARetrievableObjectException is thrown. 14. boolean getOwnership(Object name, int timeout) throws CacheException GetOwnership will claim the ownership of the object, name, for this instance of CacheAccess. If ownership is not available it will block for the specified time out period, timeout. The local cache is checked first, if the local cache doesn't hold ownership of the object, a message is sent to all other caches in the system. Ownership is only relevant for synchronized objects. Ownership is maintained until an update or invalidation completes (this includes the receipt of replies when applicable) or until ownership is explicitly released with a call to the releaseOwnership method. An instance of CacheAccess can only hold ownership of one object at a time. Ownership only applies to individual objects it is not available on groups. If ownership was obtained the boolean value of true is returned, otherwise false is returned. The name object must override the Object.equals and Object.hashCode methods. 2.3. Distributed Cache Consistency The caching service maintains cache-to-cache consistency using a broadcast reply mechanism for object invalidation and update. When an application invalidates or updates an object, the caching service broadcasts the invalidation or update to all caches. To insure consistency of a cached object across caches the application can request a reply from all remote caches indicating the modification has completed. If a high level of consistency is required, the application should wait for the replies before committing the change to the definitive storage (the database or directory). The replies are received asynchronously so the application can do other work while waiting for the reply. If the consistency requirements are less stringent, the application can do the invalidation or update without a reply or, for invalidation, a time to live attribute can be used. To help coordinate multiple updates within the cache, the cache manager offers a concept of object ownership. Cached objects can be owned by a reference to the object. If an object is declared for synchronized update, the updating reference must "own" the object before the update can occur. Only one reference can own an object at a time. A reference can request ownership of an object at anytime. If the current owner is not updating the object the ownership will be transferred to the requester. If an update is underway, it must complete before ownership can be transferred. If ownership currently resides at the requesting process, the request is a local operation. Otherwise the request is broadcast to all caches in the site. Synchronized updates only synchronize between objects in the cache. There is no relationship with external data sources. Synchronized updates are not defined for group objects. Object ownership has no effect on read access to an object. Cache updates are not inherently transactional. If an object in the cache is updated before the database update commits, then the database update fails, the cache update is not automatically rolled back. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
