You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Aaron Korver <aa...@gmail.com> on 2010/06/18 00:20:02 UTC

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

RE: Strange unexpected behavior with Version_Series_Checked_Out

Posted by Jens Hübel <jh...@opentext.com>.
Aaron,

what is your repository you are testing against? Your problem could also indicate an issue on the server side.

Jens


-----Original Message-----
From: Aaron Korver [mailto:aaron.korver@gmail.com] 
Sent: Freitag, 18. Juni 2010 00:20
To: chemistry-dev@incubator.apache.org
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

RE: Strange unexpected behavior with Version_Series_Checked_Out

Posted by Florian Müller <fm...@opentext.com>.
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:aaron.korver@gmail.com] 
Sent: Freitag, 18. Juni 2010 17:35
To: Florian Müller
Cc: chemistry-dev@incubator.apache.org
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 <fm...@opentext.com> 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:aaron.korver@gmail.com]
Sent: Freitag, 18. Juni 2010 00:20
To: chemistry-dev@incubator.apache.org
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

 


Re: Strange unexpected behavior with Version_Series_Checked_Out

Posted by Aaron Korver <aa...@gmail.com>.
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 <fm...@opentext.com>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:aaron.korver@gmail.com]
> Sent: Freitag, 18. Juni 2010 00:20
> To: chemistry-dev@incubator.apache.org
> 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
>

RE: Strange unexpected behavior with Version_Series_Checked_Out

Posted by Florian Müller <fm...@opentext.com>.
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:aaron.korver@gmail.com] 
Sent: Freitag, 18. Juni 2010 00:20
To: chemistry-dev@incubator.apache.org
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