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 <[EMAIL PROTECTED]> 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
