What can cause a gap between RTC Work Item IDs?
We've noticed that a Work Item ID for new Work Item does not always follow sequentially from the last created Work Item. We just had a case where we created a Work Item (ID was 16928), rebooted the RTC server, and the next Work Item created had an ID of 17001. Why this gap in IDs? Is this to be expected after a reboot?
We're running RTC 5.0.1, using Tomcat, and an Oracle database, Linux server.
2 answers
the rules for incrementing the workitem id counter are not documented.
there is only one counter for an entire CCM instance, and that means all projects share the same counter.
so a new workitem in project C might get 9, project A will get 10, in project B maybe 11, and project C again might get 12. while the number are sequential, they do not appear that way, as u can only see workitems one project at a time.
there have been discussions that an id is assigned to a workitem when the create workitem request is done, even if that workitem creation is abandoned. (so that number is not used at all)
there is only one counter for an entire CCM instance, and that means all projects share the same counter.
so a new workitem in project C might get 9, project A will get 10, in project B maybe 11, and project C again might get 12. while the number are sequential, they do not appear that way, as u can only see workitems one project at a time.
there have been discussions that an id is assigned to a workitem when the create workitem request is done, even if that workitem creation is abandoned. (so that number is not used at all)
Comments
 We only have a single Project Area, so that is not our issue. Any other thoughts? The last occurrence of this happening (with a gap of 73, jumping from 16928 to 17001) was immediately after rebooting the server.
sorry, no idea..
gotta ask, why do you care? is there some process you might depend on sequential numbers? (which IBM does not guaranty)