It's all about the answers!

Ask a question

Stale Data problem in plain client


Michael Baylis (1832719) | asked Jun 22 '10, 5:00 a.m.
Hi,
I have a bit of code that will run a saved query every minute which looks for workitems with a specific tag. The code will then perform an action and remove the tag. This works perfectly except for one little problem. If I manually re-add the tag to the workitem just processed, the routine fails when attempting to save the workitem with a stale data problem:-


com.ibm.team.workitem.common.model.MultiStaleDataException: Stale Data

at com.ibm.team.workitem.common.internal.util.Utils.checkSaveResult(Utils.java:282)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.saveWorkItems(WorkItemWorkingCopyRegistry.java:1741)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.saveAffected(WorkItemWorkingCopyRegistry.java:1637)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.save(WorkItemWorkingCopyRegistry.java:1538)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.save(WorkItemWorkingCopyRegistry.java:1509)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyManager.save(WorkItemWorkingCopyManager.java:115)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyImpl.save(WorkItemWorkingCopyImpl.java:221)
at com.ibm.hursley.cicsts.test.ste.regression.scheduler.WorkItemScheduler.addComment(WorkItemScheduler.java:211)
at com.ibm.hursley.cicsts.test.ste.regression.scheduler.WorkItemScheduler.processWorkItem(WorkItemScheduler.java:137)
at com.ibm.hursley.cicsts.test.ste.regression.scheduler.WorkItemScheduler.performRTCScan(WorkItemScheduler.java:106)
at com.ibm.hursley.cicsts.test.ste.regression.scheduler.WorkItemScheduler.run(WorkItemScheduler.java:69)


This is an abstract of the code I am using:-

IQueryResult<IResult> results = queryClient.getQueryResults(runquery);
results.setPageSize(500);
results.setLimit(Integer.MAX_VALUE);

List<IWorkItemHandle> workitemhandles = new ArrayList<IWorkItemHandle>(results.getResultSize(null).getTotal());

System.out.println("Query returned " + results.getResultSize(null).getTotal() + " work items");

while(results.hasNext(null)) {
IResult result = results.next(null);

workitemhandles.add((IWorkItemHandle) result.getItem());
}


private List<IWorkItem> retrieveWorkItems(List<IWorkItemHandle> workitemhandles) throws TeamRepositoryException {

List<IWorkItem> listWorkItems = repository.itemManager().fetchCompleteItems(workitemhandles, IItemManager.DEFAULT, null);

System.out.println("Retrieved " + listWorkItems.size() + " work items");


return listWorkItems;
}



	private void addComment(IWorkItem workitem, String comment, boolean addScheduledTag)  {

System.err.println("W" + workitem.getId() + "Adding comment " + comment);
IWorkItemClient workItemClient = (IWorkItemClient)repository.getClientLibrary(IWorkItemClient.class);

IWorkItemWorkingCopyManager workingCopyManager = workItemClient.getWorkItemWorkingCopyManager();
try {
workingCopyManager.connect(workitem, IWorkItem.FULL_PROFILE, null);
} catch (TeamRepositoryException e) {
e.printStackTrace();
}
WorkItemWorkingCopy workingCopy = workingCopyManager.getWorkingCopy(workitem);

IComments comments = workingCopy.getWorkItem().getComments();
IComment newComment = comments.createComment(repository.loggedInContributor(), XMLString.createFromPlainText(comment));
comments.append(newComment);

removeRequestedTag(workingCopy);
if (addScheduledTag) {
addSceheduledTag(workingCopy);
}

IDetailedStatus status = workingCopy.save(null);
if (!status.isOK()) {
System.err.println("Failed to save workitem : " + status.getDetails());
} else {
System.err.println("Saved Data");
}


return;
}



How do I ask the client to dispose of the cached workitem or tell it to refresh it so that I don't get the stale data problem?


thank you,

Michael Baylis
IBM Hursley

4 answers



permanent link
Patrick Streule (4.9k21) | answered Jun 23 '10, 3:48 a.m.
JAZZ DEVELOPER
Hi Patrick,
I think I have found the problem, but would like confirmation please.
I have put the REFRESH back in. But I realised that I had this bit of
code

workingCopyManager.connect(workitem,
IWorkItem.FULL_PROFILE, null);

but I didn't have a disconnect. I have put in a disconnect and it
looks like it is working correctly now. I assume that the second
connect would have realised that it was already in the
workingcopymanager and not bothered to update it, so my second pass
was updating the working copy of the first pass?


Yes, you are right. A fresh connect will refresh the working copy, while
a second connect will connect to the existing instance, which might not
be in the newest state.

--
Regards,
Patrick
Jazz Work Item Team

permanent link
Patrick Streule (4.9k21) | answered Jun 22 '10, 5:18 a.m.
JAZZ DEVELOPER
How do I ask the client to dispose of the cached workitem or tell it
to refresh it so that I don't get the stale data problem?

Instead of

List<IWorkItem> listWorkItems =
repository.itemManager().fetchCompleteItems(workitemhandles,
IItemManager.DEFAULT, null);

use

List<IWorkItem> listWorkItems =
repository.itemManager().fetchCompleteItems(workitemhandles,
IItemManager.REFRESH, null);


--
Regards,
Patrick
Jazz Work Item Team

permanent link
Michael Baylis (1832719) | answered Jun 22 '10, 7:44 a.m.
List<IWorkItem> listWorkItems =
repository.itemManager().fetchCompleteItems(workitemhandles,
IItemManager.REFRESH, null);


Hi Patrick,
I have previously tried using REFRESH and that makes no difference. Only tried DEFAULT today to see if it makes a difference.

Cheers,

Michael

permanent link
Michael Baylis (1832719) | answered Jun 22 '10, 9:47 a.m.
List<IWorkItem> listWorkItems =
repository.itemManager().fetchCompleteItems(workitemhandles,
IItemManager.REFRESH, null);


Hi Patrick,
I think I have found the problem, but would like confirmation please. I have put the REFRESH back in. But I realised that I had this bit of code

workingCopyManager.connect(workitem, IWorkItem.FULL_PROFILE, null);


but I didn't have a disconnect. I have put in a disconnect and it looks like it is working correctly now. I assume that the second connect would have realised that it was already in the workingcopymanager and not bothered to update it, so my second pass was updating the working copy of the first pass?

Cheers

Michael

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.