Cunning plan required

[David Garratt]

I am working on an application which has a need to generate unique sequential numbers from both a full blown java swing application running on a networked workstation and/or and portable wirless device running a web based application. I want to keep the application database neutral and avoid any proprietary tricks like Oracle ssequences etc. I have thought about using either the users workstation or username to act as a partial key in a database field to avoid any record locking/consistency problems in the database table that holds the next number to use as a single record. However I'm having second thoughts. Is there a better way, perhaps using a servelet or something similar which I'm running to support the web part of my application which I can call from both the web app and the desktop app to get a unique number. I've probably not explained to well but if you understand and have any similar experience or suggestions before I go off in the wrong direction I would be very grateful.

Thanks

Dave

[Ulf Dittmer]

Are you familiar with the java.util.UUID class? That does something along those lines.

[Ernest Friedman-Hill]

Note that this is a continuation of this thread.

[Stan James]

I like compound keys. Get one part from some source, say a database sequence number, and construct the other part in code. I used one with a 10-digit sequence from the database plus a 3 digit sequence in the app server. The app server requested a new sequence from the db at startup and after every 1000 keys.

Your disconnected clients could get a high-order-part for the key before going remote. Or maybe they could operate with only their low-order part while disconnected, and map those keys to compound keys while uploading to the central app?

We rejected UUID because users had to see and talk about "case numbers" for ongoing work. We inserted punctuation in the compound key to make it easier to look at: 12345-67890-123.

[David Garratt]

I agree, however in this case I don't see how I can use them. It's my fault for not explaining in more detail the application requirements. Basically I need to generate pallet numbers (SSCC's Standard Shipping Container Codes) which are 18 digit long numbers. The structure is documented with the 1st part identifying the country and company of origin, followed by the sequential number part, followed by a check digit. I can store the prefix in a control table and calculate th check digit on the fly, but I do need a way of ensure in a multi user enviroment that when 5 users simulatenously press print they get pallet numbers :-

xxxxxxxxxx0000000x
xxxxxxxxxx0000001x
xxxxxxxxxx0000002x
xxxxxxxxxx0000003x
xxxxxxxxxx0000004x

I absolutely cannot have two labels with the same number.

Thanks and sorry for my incomplete explanation.

Dave

[Stan James]

If they come through a single server you can just increment in server memory.

If you have servers in a cluster you'll need a central key vendor or some kind of compound key scheme.

If they generate keys while disconnected, I'd lean toward some kind of compound key. Any way to defer making up the keys until they upload to the central server? Use a temporary bogus key while disconnected?

Reminds me of an API I provided a couple years ago ... Clients sent new data in fire & forget message queues. They generated a key that was guaranteed unique PER CLIENT and I maintained a map of their proprietary keys to my guaranteed unique keys. That way they could come back and look things up later by their client keys.

Seven digits is not much to work with! How long will it take to write 10 million of these? In my last system 10 million keys would only last a few days.