Processing Input

[JohnP]

So the psuedo code goes like this. The locking is required for it to be single-threading.

Code: Select all

validate the transaction exclusively lock something allocate the number, persist it unlock something

[allistar]

So the psuedo code goes like this. The locking is required for it to be single-threading.

Code: Select all

validate the transaction exclusively lock something allocate the number, persist it unlock something

That would work, depending on the approach you take. Typically it would be something like:

Code: Select all

beginTransaction validate the inputs do all persisted object updating exclusively lock something (an object that holds the next available id, or a simple mutex that can be accessed from a root singleton) allocate the number commuitTransaction

When you lock the mutex or next-number-holder, lock it with a duration of "transaction". This means that when the database transaction is committed or aborted the lock will be let go - you don't have to explicitely release the lock.
If the unique number you're allocating is the key in a collection (which is quite likely) then you'll want to add the object to the collection (via automatic inverse maintenance) after you've assigned the number. This will save on unnecessary collection maintenance.

[Dr Danyo]

Hi Omash,

Following on from BeeJay's advice on contiguous numbers.

If the number is displayed / returned externally for any purpose; I'd recommend caution using a contiguous number strategy, you could inadvertently be leaking valuable data about your business which a competitor may find useful e.g to work out how many registered customers you have and your rate of sign ups; all they would have to do is periodically create a new customer and measure the differences in customer numbers.

In terms of allocating a unique number, as I think others have mentioned, you don't have to do it then and there; rather you could add the customer to a work collection and let a single threaded background task allocate an appropriate number at a later point.

You have not mentioned what the number is used for; so I'm not sure if the above is an option or not, if its as a login id, I'd suggest email or user name rather than a number.

Hope the above helps - Dr Danyo.

[M45HY]

Hi Guys,

First and foremost, thank you all for the feedback.

@Dr Danyo: Hi Dr Danyo. The number that we use is not the amount of customers/clients we have. The initial number is generated and then the number is incremented. E.g. If you were the first ever customer, the system could say that your number is 789463 and then start incrementing from there on. The 7 in 789463 - for example - could tell us whether the details have been keyed in from the browser or software. The number is used just so that the person can be easily found, such as a reference number for an individual's car insurance policy. However, this number needs to be seen by the client so that they can search it. It wouldn't be right if a client tried to create a new customer and the system displayed a number but decides to assign it with another number so that when the client searches it; the data would be for another record.

I was discussing this with my boss and we were thinking that similarly to the exclusive lock, when a new customer is about to be seleceted, the system creates an instance with that number, which will prevent anyone from keying in to the same customer. But just thinking about it, what would happen if 2+ clients entered the page simultaneously? I'm not asking to be spoon-fed the answer (as I wouldn't be learning anything) but I was wondering whether someone could give an example of how the system could exclusively lock a number?

Thank you everyone; you're all a true help.

Omash

[murray]

It's more about locking the object that the number is stored on, rather than the number itself.
You may either have a singleton object that allocates numbers, e.g. NumberAllocator.getNextCustomerNumber().
However, to avoid multiple processes accessing the number or method simultaneously you need to exclusively lock the single common object.
This is still the case, even if you were to create multiple CustomerNumber objects, each with a unique key value.