De : "Ray Barlow" <[EMAIL PROTECTED]> > 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 <[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 > >>> > >>> > >>> > >> > > > > > >
