advice how to use caching from the cmis client

[Nicolae Marasoiu <Ni...@computas.com>]

Hi,

I was looking for a "user" maillist, not a "dev" one, but I could not find it, so I will put my user question here:

I am scared how the cache will behave on getObjByPath on a folder deleted than added back, and more generally, since the cache seems read-only, and since there seems not to be any mechanism to replicate changes in the content repo back to the client caches, how would the cache interact with concurrency and trying to update old data - is there any optimistic/pesimistic locking part of the scheme, and does it include the cache in its flow? How does one make sure that it does not override changes made by another user/process? 

Is there a bidirectional version of the cache? I guess not, since CMIs does not include any "push" notifications from the server side back to clients on changes.

Seems the safest way is to go without cache, or cache things for the small duration of the "request" processing, such as caching the obj id of a folder where many children will be added.

What is your advice/experience with this?

Thanks,
Nicu

Re: advice how to use caching from the cmis client

[Florian Müller <fm...@apache.org>]

Hi Nicu,

This is right mailing list.

The OpenCMIS client lib maintains a Path-to-ID cache. Each cache entry 
is kept for 30 minutes. The cache can be disabled, and the TTL and cache 
size can be configured - see [1].
When you delete a folder, the cache entry in the current session is 
removed, too. Other sessions still have the outdated cache entry and 
provide an object that doesn't exist anymore.

The cache is not read-only. You can remove objects from the cache if you 
know that they are outdated. Like this:


Folder folder = null;
try {
   folder = (Folder) session.getObjectByPath("/my/folder");
   folder.refreshIfOld(2000);
}
catch(CmisObjectNotFoundException e) {
   session.removeObjectFromCache(folder);

   try {
     // it cannot be in the cache anymore and must be fetched from the 
server
     folder = (Folder) session.getObjectByPath("/my/folder");
   }
   catch(CmisObjectNotFoundException e) {
     // there is no object at this path anymore
   }
}


The question is if this is any better than disabling the cache. It's 
only a good option if your application logic can somehow determine that 
an object is outdated.


In general, CMIS has the concept of optimistic locking (if the 
repository supports that). Each object has a change token as a property. 
If the client provides this token in an update operation (OpenCMIS does 
this automatically if a change token is present), the server can check 
if it has been changed and throws a update conflict exception if there 
is a conflict.
But this does affect the cache.


- Florian


[1] 
https://chemistry.apache.org/java/0.12.0/maven/apidocs/org/apache/chemistry/opencmis/commons/SessionParameter.html



> Hi,
> 
> I was looking for a "user" maillist, not a "dev" one, but I could not
> find it, so I will put my user question here:
> 
> I am scared how the cache will behave on getObjByPath on a folder
> deleted than added back, and more generally, since the cache seems
> read-only, and since there seems not to be any mechanism to replicate
> changes in the content repo back to the client caches, how would the
> cache interact with concurrency and trying to update old data - is
> there any optimistic/pesimistic locking part of the scheme, and does
> it include the cache in its flow? How does one make sure that it does
> not override changes made by another user/process?
> 
> Is there a bidirectional version of the cache? I guess not, since CMIs
> does not include any "push" notifications from the server side back to
> clients on changes.
> 
> Seems the safest way is to go without cache, or cache things for the
> small duration of the "request" processing, such as caching the obj id
> of a folder where many children will be added.
> 
> What is your advice/experience with this?
> 
> Thanks,
> Nicu