You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Walter Vaughan <wv...@steelerubber.com> on 2007/08/23 15:46:57 UTC
SequenceValueItem
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
Re: SequenceValueItem
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Ray Barlow" <ra...@makeyour-point.com>
> 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 <jo...@improov.com> 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
> >>>
> >>>
> >>>
> >>
> >
> >
> >
Re: SequenceValueItem
Posted by Ray Barlow <ra...@makeyour-point.com>.
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 <jo...@improov.com> 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
>>>
>>>
>>>
>>
>
>
>
Re: SequenceValueItem
Posted by Jonathon -- Improov <jo...@improov.com>.
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 <jo...@improov.com> 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
>>>
>>>
>>
>
>
Re: SequenceValueItem
Posted by Chris Howe <cj...@yahoo.com>.
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 <jo...@improov.com> 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
> >
> >
>
>
Re: SequenceValueItem
Posted by Jonathon -- Improov <jo...@improov.com>.
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
>
>