SequenceValueItem
Locked
 
|
Why are all the values that are stored in SequenceValueItem multiples of 10?
What was the logic/reason? Reading this http://confluence.atlassian.com/display/JIRA/Merging+2+JIRA+instances it gave a reason that it needs to be higher to avoid dupicate keys, but wouldn't n+1 worked just as well as the formula to round up to the next multiple of 10? Thanks == Walter |
|
|
Walter,
I think it can be configured to be n+1 rather than n+10. Can even be n+anything. One reason why there are gaps in the sequence numbers is so we have the freedom of inserting values that may be missing somehow. But if we ever needed to do that, something is terribly amiss with the software we built. I don't know about the reason given in the docs you highlighted. Jonathon Walter Vaughan wrote: > Why are all the values that are stored in SequenceValueItem multiples of > 10? What was the logic/reason? > > Reading this > http://confluence.atlassian.com/display/JIRA/Merging+2+JIRA+instances > > it gave a reason that it needs to be higher to avoid dupicate keys, but > wouldn't n+1 worked just as well as the formula to round up to the next > multiple of 10? > > Thanks > > == > Walter > > |
|
|
I thought it was n+10 because it cached those ten keys for use (each
key n+1, n+2, n+3 is still used), thus resulting in 90% less database round trips (than n+1) to determine keys that should generally only have meaning to the application (machine) and not to people. You'll get the gaps in key numbers when the cache is cleared before the keys are used up. --- Jonathon -- Improov <[hidden email]> wrote: > Walter, > > I think it can be configured to be n+1 rather than n+10. Can even be > n+anything. > > One reason why there are gaps in the sequence numbers is so we have > the freedom of inserting > values that may be missing somehow. But if we ever needed to do that, > something is terribly amiss > with the software we built. > > I don't know about the reason given in the docs you highlighted. > > Jonathon > > Walter Vaughan wrote: > > Why are all the values that are stored in SequenceValueItem > multiples of > > 10? What was the logic/reason? > > > > Reading this > > > http://confluence.atlassian.com/display/JIRA/Merging+2+JIRA+instances > > > > it gave a reason that it needs to be higher to avoid dupicate keys, > but > > wouldn't n+1 worked just as well as the formula to round up to the > next > > multiple of 10? > > > > Thanks > > > > == > > Walter > > > > > > |
|
|
Chris,
Yes, I recall something like that too. Each retrieval of a new unique key requires a DB access to "SequenceValueItem". Jonathon Chris Howe wrote: > I thought it was n+10 because it cached those ten keys for use (each > key n+1, n+2, n+3 is still used), thus resulting in 90% less database > round trips (than n+1) to determine keys that should generally only > have meaning to the application (machine) and not to people. You'll > get the gaps in key numbers when the cache is cleared before the keys > are used up. > > --- Jonathon -- Improov <[hidden email]> wrote: > >> Walter, >> >> I think it can be configured to be n+1 rather than n+10. Can even be >> n+anything. >> >> One reason why there are gaps in the sequence numbers is so we have >> the freedom of inserting >> values that may be missing somehow. But if we ever needed to do that, >> something is terribly amiss >> with the software we built. >> >> I don't know about the reason given in the docs you highlighted. >> >> Jonathon >> >> Walter Vaughan wrote: >>> Why are all the values that are stored in SequenceValueItem >> multiples of >>> 10? What was the logic/reason? >>> >>> Reading this >>> >> http://confluence.atlassian.com/display/JIRA/Merging+2+JIRA+instances >>> it gave a reason that it needs to be higher to avoid dupicate keys, >> but >>> wouldn't n+1 worked just as well as the formula to round up to the >> next >>> multiple of 10? >>> >>> Thanks >>> >>> == >>> Walter >>> >>> >> > > |
|
|
In reply to this post by cjhowe
Round trip db access was the reason I understood for the n+10. I haven't
checked but I would not have expected this cache to clear like the normal entity cache model. Caching query aside you will get gaps occur when/if the application server restarts. In summary it reads the next DB value say 10000, increments it by 10 as a default, commits that value 10010 to the DB. If before all the cached values are used the server restarts it'll start again from 10010, hence the gaps. A nice feature to add would be the ability to control the increment value on an entity basis rather than the current setting for all. On a busy site 20 or more cached values for visitor entities would be worthwhile as the speed is important but you might still prefer sequential order id's with no gaps and be happy to take the slight performance hit depending on the number of orders you get. Ray Chris Howe wrote: > I thought it was n+10 because it cached those ten keys for use (each > key n+1, n+2, n+3 is still used), thus resulting in 90% less database > round trips (than n+1) to determine keys that should generally only > have meaning to the application (machine) and not to people. You'll > get the gaps in key numbers when the cache is cleared before the keys > are used up. > > --- Jonathon -- Improov <[hidden email]> wrote: > > >> Walter, >> >> I think it can be configured to be n+1 rather than n+10. Can even be >> n+anything. >> >> One reason why there are gaps in the sequence numbers is so we have >> the freedom of inserting >> values that may be missing somehow. But if we ever needed to do that, >> something is terribly amiss >> with the software we built. >> >> I don't know about the reason given in the docs you highlighted. >> >> Jonathon >> >> Walter Vaughan wrote: >> >>> Why are all the values that are stored in SequenceValueItem >>> >> multiples of >> >>> 10? What was the logic/reason? >>> >>> Reading this >>> >>> >> http://confluence.atlassian.com/display/JIRA/Merging+2+JIRA+instances >> >>> it gave a reason that it needs to be higher to avoid dupicate keys, >>> >> but >> >>> wouldn't n+1 worked just as well as the formula to round up to the >>> >> next >> >>> multiple of 10? >>> >>> Thanks >>> >>> == >>> Walter >>> >>> >>> >> > > > |
Administrator
|
De : "Ray Barlow" <[hidden email]> > Round trip db access was the reason I understood for the n+10. I haven't > checked but I would not have expected this cache to clear like the > normal entity cache model. > > Caching query aside you will get gaps occur when/if the application > server restarts. In summary it reads the next DB value say 10000, > increments it by 10 as a default, commits that value 10010 to the DB. If > before all the cached values are used the server restarts it'll start > again from 10010, hence the gaps. > > A nice feature to add would be the ability to control the increment > value on an entity basis rather than the current setting for all. On a > busy site 20 or more cached values for visitor entities would be > worthwhile as the speed is important but you might still prefer > sequential order id's with no gaps and be happy to take the slight > performance hit depending on the number of orders you get. +1, Why not opening a Jira issue ? Jacques > Ray > > > > Chris Howe wrote: > > I thought it was n+10 because it cached those ten keys for use (each > > key n+1, n+2, n+3 is still used), thus resulting in 90% less database > > round trips (than n+1) to determine keys that should generally only > > have meaning to the application (machine) and not to people. You'll > > get the gaps in key numbers when the cache is cleared before the keys > > are used up. > > > > --- Jonathon -- Improov <[hidden email]> wrote: > > > > > >> Walter, > >> > >> I think it can be configured to be n+1 rather than n+10. Can even be > >> n+anything. > >> > >> One reason why there are gaps in the sequence numbers is so we have > >> the freedom of inserting > >> values that may be missing somehow. But if we ever needed to do that, > >> something is terribly amiss > >> with the software we built. > >> > >> I don't know about the reason given in the docs you highlighted. > >> > >> Jonathon > >> > >> Walter Vaughan wrote: > >> > >>> Why are all the values that are stored in SequenceValueItem > >>> > >> multiples of > >> > >>> 10? What was the logic/reason? > >>> > >>> Reading this > >>> > >>> > >> http://confluence.atlassian.com/display/JIRA/Merging+2+JIRA+instances > >> > >>> it gave a reason that it needs to be higher to avoid dupicate keys, > >>> > >> but > >> > >>> wouldn't n+1 worked just as well as the formula to round up to the > >>> > >> next > >> > >>> multiple of 10? > >>> > >>> Thanks > >>> > >>> == > >>> Walter > >>> > >>> > >>> > >> > > > > > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |