"Unique ID" server for multi-server app

"Unique ID" server for multi-server app

• Camalot

  You could also run the web service directly in SQL Server if you're concerned about the web service not beinf there. Database mirroring is a reasonable and relatively cheap way to provide redundancy. Because the messaging is not reliable, there is some risk that a unique ID might be successfully created in the database and then the response is lost so the caller is not sure whether it worked or not. This might be the right place to use your GUID. If the caller gets a timeout, it could retry query for the ID with the same GUID and if it exists in the database then the caller can assume the insert worked and the response was lost.
  

• Jed Atreides

  Some versions of UUID/GUID rely on the mac address and only have a pseudo-random number if there is no network card - other versions rely on other algorithms. You can read about it here : http://ietfreport.isoc.org/rfc/PDF/rfc4122.pdf (e.g. sections 4.3 and 4.4)

  Arnon

  
  
  

• Suyog

  RMD wrote:

  One simple approach for lookups that must be very quick is to utilze a "check first" caching scheme.

  Another option is to reserve IDs - a client can reserve a range or a predefined number of IDs from the server and then it can use them as needed (as well as reserve some more)

  Arnon

  
  
  

• Samuel Zhang

  I think you can avoid staying up night worrying about GUID uniqueness. At least on thing you may have heard of - COM - depends on GUID uniqueness. There are thousands of distributed systems out there that assume GUIDs are unique so I don't think you need to design your system around assuming there may be duplicates - especially if you are going to use and ExternalID and a GIUD both as you statedin your orriginal proposal. The chances of both of them not forming a unique identifier are too small to consider.
  

• Hitchhiker

  Thanks for the input. The feature has two main requirements: uniqueness and distribution. I can see that your suggestion satisfies both.

  I've had a concern about Web Service because if the server goes down it's got to be restarted, though I this URL has information about how a windows service might do that.

  http://msdn.microsoft.com/msdnmag/issues/05/03/SchedulingASPNETCode/

  Otherwise, I guess it's a balance between "single-store" for uniqueness, and then some kind of redundancy if that single-store is down. But the latter is more of an operational implementation that a general design issue, and I suspect it's covered somewhere in the realm of SQL Server.

  
  

• developer_bill

  If you're going to all this trouble to make sure the ID is unique, I don't really understand the need for a GUID but that's another question. The simplest implementation would proably be a web service that accepts an ID as a parameter and tries to insert it into a column in a SQL Server table with a unique constraint. If the insert fails with a uniqueness violation then tell the user to try again. If you want to save the user a lot of guessing, you could append a number to their ID if it fails, keep trying until it works and then return the one that works. This might be risky because they will probably remember the ID they supplied but not the number you appended to it. SQL will do all the appropriate locking to ensure that simultaneous requests for the same ID will be handled correctly.
  

• funklessbeavers

  Thanks for the post.

  One question that comes to my mind on this point has to do with the uniqueness of GUID's.

  In some posts and articles I get the message that the chances of a GUID being duplicated are infintesimally small, but in other posts and articles there's some kind of little caveat about "provided there's (some condition with respect to) the (the network card, or other hardware element)".

  Any clarification on this point would be appreciated.

  Thanks!

  
  

• JJ Lawrence

  On point to think about in the solution suggested by Roger is - will you get to a point where you'd need to scale the SQL Server if you see this happening you need to make sure that the key is data partition ready -so that the data can be partitioned between multiple servers and it would still be easy to insure uniqueness.

  Arnon

  
  
  

• dsdsds

  Thanks. I appreciate the input. I recognized there's no reason to skip the exception check on insert in any case. So now I can consider the other attractions of the GUID, such as uniqueness when thrown together with data from a different instantiation of the same schema (did I say that right :-)
  

• frister

  Thanks for input. I'm going to need to do some research on your comments, but I'm getting the idea that there are well-developed technologies to support the requirement. That's going to help a lot in the development planning.

  
  

• Vlado H

  Thanks for the latest inputs. (I find it interesting that this thread has gotten so many views...looks like a product is needed in this area...)

  Arnon, thanks for the link on the GUID standard. Unfortunately I'm still not left with a warm fuzzy feeling about GUID uniqueness. For an action standpoint, it gets down to whether you can "trust" the GUID enough to "expect" it to be unique (and therefore relax exception checking in some cases). But maybe that's the real issue...you NEVER should relax exception checking.

  The other point, with respect to caching unique ID's, runs into another area that I'm not familiar with, which is multi-server app operation. The problem seems to be that the ID may be unique in "this" server's "view", but not unique in the view of both "this" server AND "that" server.

  This probably goes back to application or database partitioning...which probably is why "virtualization" products for servers are doing so well. If a virtual server can provide just "one big logical machine", then maybe you don't have to partition the app or the data.

  
  

• WLW

  One simple approach for lookups that must be very quick is to utilze a "check first" caching scheme.
  
  The idea here is that if you cache a list of taken "external IDs" in memory (in a hashtable, for instance) there is a very good chance that if the ID is taken it's in memory and the check will be very fast.
  
  If you don't find the ID in memory you then check the database directly, either by doing an INSERT and catching any constraint exceptions or just be calling a stored procedure that does the check for you.
  
  Periodically you update your in memory cache with a fresh list. How often you do this really depends on how often new users are added to your system.
  
  At any rate, the cache doesn't have to be always up to date, just up to date enough to contain most of the taken IDs.
  
  
• "Unique ID" server for multi-server app