IBM Case Manager: Intermittantly getting "Update sequence number mismatch" trying to save case

Question

I'm using the Java API with Case Manager 5.2.1, on Windows.

My web service does the following:

// Create a brand new case
CaseType myCaseType = CaseType.fetchInstance(osRef, myCaseTypeName);
Case newPendingCase = Case.createPendingInstance(myCaseType);

// Save it now to get access to the Case ID
newPendingCase.save(RefreshMode.REFRESH, null, ModificationIntent.MODIFY);
newCaseIdentifier = newPendingCase.getIdentifier();

// Fetch a fresh copy of the case instance
Case cs = Case.fetchInstanceFromIdentifier(osRef, newCaseIdentifier);

// Now set a whole bunch of properties, add documents, etc. etc.
...

// Finally, save all our updates: to "cs", not "newCaseIdentifier"
cs.save(RefreshMode.REFRESH, null, ModificationIntent.MODIFY);

PROBLEM: I intermittently get this error:

The object {52EECAC2-38B2-4CB5-8F22-BAF33D6C35EC} of class "MyCaseTypeName" was not changed or deleted because it was modified one or more times in the repository since the application retrieved it. Update sequence number mismatch; requested USN = 0, database USN = 1

I know there are only two case.save() calls: one for "newPendingDocument", the other (much later) for "cs".

I execute the SAME code multiple times: sometimes it works, sometimes if fails with the "Update sequence number mismatch" error.

Q: Any ideas/any suggestions as to how I can troubleshoot this problem?

Any chance you can post the full code? And are you certain that the client is only invoking the service once? — Christopher Powell, Jun 21 '16 at 11:55

Christopher Powell · Answer 1 · 2016-06-22T14:48:32.063

1

Looking at the code that you provide I am confused as to why you would create a second Case instance. I would imagine that you would be better off doing this instead:

// Create a brand new case
CaseType myCaseType = CaseType.fetchInstance(osRef, myCaseTypeName);
Case newPendingCase = Case.createPendingInstance(myCaseType);

// Save it now to get access to the Case ID
newPendingCase.save(RefreshMode.REFRESH, null, ModificationIntent.MODIFY);
newCaseIdentifier = newPendingCase.getIdentifier();

// Fetch a fresh copy of the case instance (not sure if this is necessary)
newPendingCase = Case.fetchInstanceFromIdentifier(osRef, newCaseIdentifier);

// Now set a whole bunch of properties, add documents, etc. etc.
...

// Finally, save all our updates: to "newPendingCase"
newPendingCase.save(RefreshMode.REFRESH, null, ModificationIntent.MODIFY);

I haven't worked with Case Manager, but have worked with P8. The api calls are very similar.

The USN number can be a little tricky. If there is any time period that you are waiting for an external call (to a 3rd party REST interface for instance) you might want to do a newPendingCase.Refresh() after the call, and then repopulate any needed properties of the case.

edited Jun 22 '16 at 14:48

answered Jun 21 '16 at 13:51

Christopher Powell

714
4
13

Thank you. The reason for the first "save()" is to get the case ID - it doesn't exist before you save the case. And yes, I'm sure the service is only being invoked once - I'm manually clicking a link on a .jsp page. Sometimes the problem occurs *the very first time* after restarting the servlet. – paulsm4 Jun 21 '16 at 15:24
Is there a specific reason why would you need to obtain the id at that point? It seems to me that you are creating two case objects, when there is only one case. (I searched for some IBM sample code, but couldn't find any, so I am just going off how most FileNet objects work). Regardless, I think posting the more of your code might help (Do you ever reference the newPendingCase object again?) I've experienced similar problems with FileNet, and usually it is a result of doing something 1 way, when I should probably do it another. – Christopher Powell Jun 21 '16 at 19:22
Very good questions. 1) Yes, I do need the ID early, 2) No, `Case.fetchInstanceFromIdentifier()` doesn't create a new case - it just creates a new reference to the (now existing) case. Also I can't add documents *BEFORE* "case.save()": the case folder doesn't exist yet. IMPORTANT POINT: On Tomcat, the problem NEVER occurs. On my colleague's WebSphere (*identical* VM, different PC), it *always* occurs. On my WebSphere VM, it's intermittant. Even with *exactly the same test inputs*. Q: 1) can I somehow "lock* the case reference during my update? or 2) somehow "refresh" my reference? – paulsm4 Jun 21 '16 at 20:46
I see what you are saying, but I don't think Java would view the two Case objects as the same. If you did `boolean cs.equals(newPendingCase);` my money would be on it returning false. At any rate, there is a `refreshFromBatch(com.filenet.api.core.UpdatingBatch ub,com.filenet.api.core.BatchItemHandle bih,ModificationIntent modIntent)` api call within the Case class that you could try; although I'm not sure if it applies. This is where the Case Manager and FileNet api's differ in their objects. The FileNet `lock()` method isn't present in this API, nor would it help. Very odd about TomCat. – Christopher Powell Jun 22 '16 at 14:37
I've modified my answer to include the save and the re-fetch. The difference between my new answer and your OP is that only one Java Case object is created. – Christopher Powell Jun 22 '16 at 14:50

IBM Case Manager: Intermittantly getting "Update sequence number mismatch" trying to save case

1 Answers1