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
