24 byte Unique Id
Hi,
I need to generate a 24 byte unique Id to for the mq correlation id (our mq host receiver is not setting the message id to correlation id. It only sets the corr id that we give in request as corr id in response)
Since we have a clustered application server environment, we need to make sure this id is unique between all the managed servers and also within a managed server.
I tried to generate an id using host+currentTime+ThreadID+randomNumber.
This turns out to be more than 24 bytes.
I was wondering if something like this will work.
during initialization:
SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
String serverName = System.getProperty(server.name);
random.setSeed(serverName.getBytes());
and calling method that does this everytime
byte[] bytes = new byte[24];
random.nextBytes(bytes);
return bytes;
If SecureRandom makes sure it generates new random bytes than the previous ones and the sequences generated between different seeds differ, this should work.
I know generating unique sequences is not a trivial task, which makes me think that the above solution might not work. My main concern is to be able to fit it within 24 bytes.
Please let me know if it will work or if not, any other solutions available.
I appreciate your help.
Thanks.
Geeth
[1400 byte] By [
Geeth12a] at [2007-10-2 2:55:44]
Why not assign the first byte to each host with a unique id, and maintain a counter on each host for the rest of the bytes? It doesn't seem that you need random ids.
Assign each host a unique id and use the date and time, along with System.nanoTime() and a bit for Daylight Savings Time (to cover the overlapping hour when the clocks get turned back).
Random is well... random. So it will repeat your Id from time to time. Since the number of id's you need is less than 2^24 it should be enough to keep and manage a counter somewhere.
I solved a similar problem with following criteria
1. it it hard to predict how many id's that will be needed in
the future so it had to be flexible
2. it had to be possible to create id's in different VM's and
servers
An id was created from following four parts.
First byte describes how many of following bytes that identifies
the creator. Second part identifies the creator and can be
things like ip number or just an increment. Third part is a byte
describing how many bytes used in part four to make the id unique
within the creator. The fourth part I used an increment.
If you use a random approach you will throw away lot of memory
since it is not likely to use 2^(8*24)=6*10^57 number of id's in
the future. The suggestion above should not need more then 7 bytes
per id but it can grow if needed.
parza at 2007-7-15 21:21:31 >
> I solved a similar problem with following criteria
> 1. it it hard to predict how many id's that will be
> needed in
> the future so it had to be flexible
That is a design/requirements/bussiness problem.
Either you expect the company to have 10,000 customers in the next 10 years or you expect them to have 100 billion.
If the business people can not or will not tell you this then you pick a number and tell them that is it and design to that.
> 2. it had to be possible to create id's in different
> VM's and
> servers
>
> An id was created from following four parts.
> First byte describes how many of following bytes that
> identifies
> the creator. Second part identifies the creator and
> can be
> things like ip number or just an increment. Third
> part is a byte
> describing how many bytes used in part four to make
> the id unique
> within the creator. The fourth part I used an
> increment.
>
> If you use a random approach you will throw away lot
> of memory
> since it is not likely to use 2^(8*24)=6*10^57 number
> of id's in
> the future. The suggestion above should not need more
> then 7 bytes
> per id but it can grow if needed.
A combination of the following attributes is suitable for most production server installs and/or company installs.
1. Ip address
2. Time stamp (resolution to a second is all that is needed with 4.)
3. Process id
4. Counter.
5. Install specific name/number.
> Either you expect the company to have 10,000 customers in the
> next 10 years or you expect them to have 100 billion.
> If the business people can not or will not tell you this then
> you pick a number and tell them that is it and design to that.
There are countless of examples of when assumptions like this
have caused major problems in the future and there exists a lot
of programs that are still running after 20 years of use.
The future is extremely hard to predict and if it is possible
with little effort to make the solution scalable, doing so
might save a lot of future work.
parza at 2007-7-15 21:21:31 >
> There are countless of examples of when assumptions
like this
> have caused major problems in the future and there exists a lot
> of programs that are still running after 20 years of use.
> The future is extremely hard to predict and if it is possible
> with little effort to make the solution scalable, doing so
> might save a lot of future work.
If you can accurately predict the future then I suggest that you find a job besides programming.
Other than that, even though Pop's local grocery store might grow to 100 stores in the next 10 years, the probability is very small that it will even grow to two. And Pop might be rather reluctant to pay for you to build an inventory control system that handles all of the needs of a 100 store company versus the current needs of one store.
Not to mention the 1000s of possible alternative scenarios... for example the single store could have 1 million customers in 10 years. Or it could have 1 customer that orders 1 million different items each time. Or 1 customer that orders 1 million of a single product each time. And on and on and on....
Now presumably you are claiming that you can build a product that has all of the following attributes.
1. It will cover ever possibilitiy
2. The initial development cost will be the same.
3. The maintainance cost, regardless of possibilities (or with no change at all) will be the same.
For the rest of us we need to keep in mind that we can't do all of the above. As such we should code what we know and not make wild guesses about imagined future possibilities.
And by the way there are numerous examples of projects that failed because the creators were trying to create the ultimate product rather than just trying to code something that worked.
> If you can accurately predict the future then I suggest that
> you find a job besides programming.
I can not and that is why choosing the more flexible one is
the best choice.
> And Pop might be rather reluctant to pay for you to build an
> inventory control system ...
> For the rest of us we need to keep in mind that we can't do
> all of the above. As such we should code what we know ...
I do not claim that it is possible to solve all possible
scenarios in one big solution. You have misunderstood me
entirely.
I agree that it is of most importance a project is pushed hard
towards its specification, not writing any more code then
needed in order to optimize the cost/benefit ratio. However,
I claim, by choosing a flexible design it is possible to
prepare the software for future changes without doing any
extra work.
> And by the way there are numerous examples of projects that
> failed because the creators were trying to create the ultimate
> product rather than just trying to code something that worked.
Yes, because they did more then prepare. They actually started
to code cool but unnecessary features.
parza at 2007-7-15 21:21:31 >
>
> I do not claim that it is possible to solve all
> possible
> scenarios in one big solution. You have misunderstood
> me
> entirely.
>
> I agree that it is of most importance a project is
> pushed hard
> towards its specification, not writing any more code
> then
> needed in order to optimize the cost/benefit ratio.
> However,
> I claim, by choosing a flexible design it is possible to
> prepare the software for future changes without doing any
> extra work.
>
Then I suggest you read what I said again.
I suggested that someone needs to make an informed estimate about what the future needs of the application might be.
Your response to that point seemed to suggest that choosing to use such an informed decision rather than just one that someone pulled out of the air was a folly.
> > And by the way there are numerous examples of
> projects that
> > failed because the creators were trying to create
> the ultimate
> > product rather than just trying to code something
> that worked.
>
> Yes, because they did more then prepare. They
> actually started
> to code cool but unnecessary features.
Wrong. There have been projects that failed simply because they tried to meet all of the needs of the business now and in the immediate future. And they failed because there was simply too much to do and they underestimated the cost (money and time) in meeting all of those demands.
It wasn't for lack of planning.
> I suggested that someone needs to make an informed estimate
> about what the future needs of the application might be.
>
> Your response to that point seemed to suggest that choosing
> to use such an informed decision rather than just one that
> someone pulled out of the air was a folly.
Research of current and future needs should always be done and
used when writing the different layers of specification together
with the client. This is praxis in the industry and should be known
without being said.
What I claim is that when the specification is defined taking
future needs into account, there are still a lot of design
decision that can be made to prepare for future changes that
is beyond the specification. If done right, they will not cause
extra work.
> Wrong. There have been projects that failed simply because
> they tried to meet all of the needs of the business now and
> in the immediate future. And they failed because there was
> simply too much to do and they underestimated the cost (money
> and time) in meeting all of those demands.
I was not wrong. Our responses to this are consistent and both
of them have occurred numerous of times.
A discussion is productive when the disagreement is identified
and discussed, not when trying to disagree for the sake of
discussing.
parza at 2007-7-15 21:21:31 >
> > I suggested that someone needs to make an informed
> estimate
> > about what the future needs of the application
> might be.
> >
> > Your response to that point seemed to suggest that
> choosing
> > to use such an informed decision rather than just one that
> > someone pulled out of the air was a folly.
>
> Research of current and future needs should always be
> done and
> used when writing the different layers of
> specification together
> with the client. This is praxis in the industry and
> should be known
> without being said.
>
And that is what I said with my first post.
> What I claim is that when the specification is
> defined taking
> future needs into account, there are still a lot of
> design
> decision that can be made to prepare for future
> changes that
> is beyond the specification. If done right, they will
> not cause
> extra work.
>
> > Wrong. There have been projects that failed simply
> because
> > they tried to meet all of the needs of the business
> now and
> > in the immediate future. And they failed because
> there was
> > simply too much to do and they underestimated the
> cost (money
> > and time) in meeting all of those demands.
>
> I was not wrong. Our responses to this are consistent
> and both
> of them have occurred numerous of times.
>
> A discussion is productive when the disagreement is
> identified
> and discussed, not when trying to disagree for the
> sake of
> discussing.
And yet you disagreed with my first statement and now seem to be agreeing with it.
I guess it is not the first time a disagreement is borndue to a misunderstanding. :)
parza at 2007-7-15 21:21:31 >
