Hi Aaron,
It really depends on your use case. The default behavior works very well for UI applications where performance is more important than the fact that objects can be a minute old. Documents and folder are not changing often in many scenarios and a slight delay is acceptable. There is no good strategy for intelligent caching in CMIS. Objects can be changed through many different channels and a CMIS client can't guess who changes what and when in a repository. The only thing we could do in OpenCMIS would be to invalidate all objects that the application modifies or that might be modified by a repository as a side effect of an action. But even that would not release the application from refreshing objects. Application developers must always be aware that the objects they are working with are snapshots that could be out of date. It is arguable if caching should be on or off by default. I have no strong opinion. There are good reasons for both options. I think we should listen to the user of OpenCMIS and find how they use the library. Any comments? Cheers, Florian From: Aaron Korver [mailto:[email protected]] Sent: Freitag, 18. Juni 2010 17:35 To: Florian Müller Cc: [email protected] Subject: Re: Strange unexpected behavior with Version_Series_Checked_Out Hi Florian, Thanks for the information regarding caching. One thing from a consumers perspective that doesn't make sense is that when I ask the session for the object via the ID I expect it to have all the latest and greatest properties set. When I use a tool such as Hibernate it does do client caching, but it is smart enough to know if the data was updated or not. Getting the object and having to always call refresh seems like a inconvenience for me, the consumer of your API. On a positive note, we've implemented the full upload, checkout, checkin cycle with Chemistry and it was all very straight forward. Thanks, Aaron Korver On Fri, Jun 18, 2010 at 3:35 AM, Florian Müller <[email protected]> wrote: Hi Aaron, I have two comments. First of all, you can't get a document by version series id. Although some repositories return the same string, these ids are conceptual different and not interchangeable. Apart from that, your code works as excepted. That reminds me that we should explain the client side caching somewhere on the Wiki... By default, caching is turned on for sessions. That is, getObject() will first look into the session cache if the object already exists there. If this is the case, it returns the object without refreshing it. That's exactly what you are seeing here. There are multiple ways to deal with that: - Perform a refresh() or refreshIfOld() on each object that getObject() returns. - Use the getObject() method that takes an additional OperationContext parameter. The OperationContext holds a flag that tells getObject() if it should use the cache or not. - Set a new default OperationContext on the session that turns caching off for all operations. - Flush the cache by calling session.clear(). That's not recommended because that makes the session forget everything ... objects, type definitions, repository info, etc. Cheers, Florian -----Original Message----- From: Aaron Korver [mailto:[email protected]] Sent: Freitag, 18. Juni 2010 00:20 To: [email protected] Subject: Strange unexpected behavior with Version_Series_Checked_Out I'm seeing something odd regarding the canceling and checking in of Documents. If I get a Document by its ID, then I check it out. Now I have the working Copy Object ID. Step 2) Cancel or Checkin the working copy. Step 3) Retrieve the Document by the version Series ID. Now here is the unexpected part. If I examine the value of the Version Series Checked Out property it says TRUE! Step 4) Do a refresh() on the document. Now examine the value of Version Series Checked Out and it will be FALSE! Below is a unit test demonstrating this behavior. I would think that the expected behavior is that when I get the document after checking in or canceling then the "Version Series Checked Out" property should be false, and I shouldn't have to do a refresh(). My suspicion is that something is getting cached somewhere that it shouldn't be. ObjectId docID = session.createObjectId("PUT_DOC_ID_HERE"); Document doc = (Document) session.getObject(docID); if (doc == null) { fail(); } ObjectId checkedoutObjID = doc.checkOut(); assertFalse(doc.isVersionSeriesCheckedOut().booleanValue()); // This is expected, since haven't pulled new properties doc.refresh(); assertTrue(doc.isVersionSeriesCheckedOut().booleanValue()); // This should now be updated. assertNotNull(checkedoutObjID); Document workingCopy = (Document) session.getObject(checkedoutObjID); assertTrue(workingCopy.isVersionSeriesCheckedOut().booleanValue()); workingCopy.cancelCheckOut(); //At this point, the isVersionSeriesCheckedOut should be false. assertTrue(workingCopy.isVersionSeriesCheckedOut().booleanValue()); //Since we can't refresh, has old values assertEquals(workingCopy.getVersionSeriesId(), doc.getId()); // version series is the same as the original docID doc = (Document) session.getObject(session.createObjectId(workingCopy.getVersionSeriesId())); // Re-pull the document (Suspect that something here is cached) System.out.println(doc.isVersionSeriesCheckedOut()); //Should be FALSE but is TRUE assertFalse(doc.isVersionSeriesCheckedOut().booleanValue()); //This fails, if comment out and do the refresh then the assert below succeeds. doc.refresh(); System.out.println(doc.isVersionSeriesCheckedOut()); assertFalse(doc.isVersionSeriesCheckedOut().booleanValue()); Thanks, Aaron Korver
