Singleton

[ashtek]

Hi,
I am working on an ASP.NET application where I need to create a unique
key in a page. When a customer clicks on the button "Generate Key" I
need to create a key which should be unique in the database. I am
plannig to create in the format MMDDYYHHMMSS.

I have written a class that generates the key:

public class GenUniqueID
{
private static readonly GenUniqueID instUnique=new GenUniqueID();

private StringBuilder strUnique=new StringBuilder("");

private GenUniqueID()
{
DateTime dtID=DateTime.Now;
strUnique.Append(dtID.Month);
strUnique.Append(dtID.Day);
strUnique.Append((dtID.Year.ToString()).Substring(2,2));
strUnique.Append(dtID.Hour);
strUnique.Append(dtID.Minute);
strUnique.Append(dtID.Second);
}

public static GenUniqueID Instance
{
return instUnique;
}

public static string UniqueID
{
get
{
return strUnique.ToString();
}
}
}

I'll call this method from my aspx page :

GenUniqueID key=GenUniqueID.Instance();
string strKey=key.UniqueID;

Will this guarantee a UNIQUE key even if two or more users from
different locations will click on "Generate Key" at the same time???

Thanks,
Ashish.

 

[Marc Gravell]

No - it won't; static fields in ASP.NET should only hold application-wide
data, and never anything session / page related (unless neatly divided such
as in a sync'd cache keyed by user). Otherwise you are just asking for a
thread race, or (in this case) for lots of users to share an id.

There are other solutions for making this available to other bits of code
(such as state), but personally I would happily pass around an object
containing this information, rather than rely on these back doors - it also
makes it easier to re-use the code outside of asp.net.

Marc

 

[DeveloperX]

No, if they press the button at the same time, or more importantly, the
request hits the server at the same time, they will receive the same
ID. You could investigate GUIDs which would be simpler.

 

[Guest]

One second is not enough to get unique key, because several users can get the
same key in one second.
I'd recomed to use either GUID for this, or add user's specific info (like
name) to your unique key

--
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[ashtek]

I do not want to use GUID because the key should be in a readable
format (like MMDDYYHHMMSS). Is there any other way I can generate this
uniquely?

 

[Guest]

Why not just use Guid.NewGuid()? That's what Guids are for. You can store
them in the database as type UNIQUEIDENTIFIER.
Peter

 

[ashtek]

I am sorry but I could not understand the solution you suggested.
can you please show me a sample code ?
- Ashish

 

[Guest]

Add to your key User's details, hash of client's browser/system info,
client's IP, and some rand number
It should be enough

--
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Marc Gravell]

Well, I was mainly just observing that your use of static is not safe here;
unless I am mis-reading your code, it will keep issuing the same key (from
the first time it is used) over-and-over-and-over.

Other people have observed that your key format is also not safe (multiple
hits in a second).

Also note that your code doesn't actually follow this format, as at 1am it
will (if I read correctly) insert only "1", not "01".

So basically, you have a job on!

I would simply have an instance class (no statics) which generates a key,
and I would probably delegate key generation to the database. Otherwise you
cannot possibly compensate for different servers in a cluster (not sure if
this is an issue for you; I suspect not). But a guid should work...

I think you really need to revisit what you are trying to do, and firgure
out a scheme that allows for lots of hits per second, doesn't allow simple
guessing (i.e. incrementing second-by-second through a single day could
probably guess an ID), etc...

Marc

 

[Tom Porterfield]

I do not want to use GUID because the key should be in a readable
format (like MMDDYYHHMMSS). Is there any other way I can generate this
uniquely?

The string representation of GUID is just as readable as MMDDYYHHMMSS. If
you are trying to use the key for dual purposes to be both a unique value
and an indicator as to when it was created, then I suggest you redesign this
to have the unique key be the unique key and use a separate value to hold a
timestamp as to when the record was generated.

 

[ashtek]

Yes, it returns the same key everytime!
I think I would go with delegating the key generation to the database.
Thanks for your suggestion.

But I am just wondering if it is possible to lock a method or prevent
creating another instance of the class while it is generating the key
for one request. The second request will be in a queue during this
time.
Hope it is not sounding crazy!

-Ashish.

 

[Marc Gravell]

Well, yes you could do this... but you will still have to throttle this to
one a second to meet your format limitations. Of course, without the format
you have chosen (i.e. with an incrementing ID from the database, or a guid)
you don't even have to do this locking : you can unleash all threads to run
full throttle. Which would be good.

Marc

 

[sloan]

Technically, you could solve the problem by:

using the lock {} statement, and Thread.Sleep (ing) for 1 second.

That's techincally, but it would be silly to do that.

http://www.informit.com/discussion/index.asp?postid=a8275a70-0698-46f0-8c8f-bf687464628c&rl=1
Look at a COMB, its a friendlier GUID I believe, though I've never done
this.

...

I know you said you don't want a Guid, but that's the best thing to use.


You could also look at using a TimeSpan object, and you can get down to the
MilliSecond there.
But you'd still need to lock it for a millisecond, just in case.


The world is going to GUID's . ... get on board ! They're not so bad after
you get used to a database with a bunch of GUID's in it.