SequenceValueItem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

SequenceValueItem

Walter Vaughan
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
Reply | Threaded
Open this post in threaded view
|

Re: SequenceValueItem

jonwimp
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SequenceValueItem

cjhowe
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
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SequenceValueItem

jonwimp
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
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SequenceValueItem

Ray Barlow
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
>>>
>>>
>>>      
>>    
>
>
>  
Reply | Threaded
Open this post in threaded view
|

Re: SequenceValueItem

Jacques Le Roux
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
> >>>
> >>>
> >>>      
> >>    
> >
> >
> >