Processing Input

[M45HY]

Hi Guys,

I've got a problem that I was hoping someone could help me overcome. The situation is that we have a webpage in which users can enter in information for a new customer (whom will be assigned a number). The problem is that when 2+ users simultaneously press the submit button, the system tries to assign both of them to the same number causing the browser to crash. Is there a way that I can prevent this from happening?

Thanks,
Omash

[allistar]

There are a couple of ways that might help:

a) don't assign then them the number until you're in the database transaction that creates the Customer object. Have an object (hanging off a root singlteon maybe) that stores the next number to be allocated. Exclusively lock that object before reading the number on it and incrementing it. This will prevent another process from getting the same number. Make sure your database transaction is short, or do the auto number allocation near the end of the database transaction to minimise contention.

b) Using the same "next number" object as mentioned previously, get and increment the next number using the same locking mechanism described previously and display that numer in the browser. When the user customer is created, use the number it was allocated. The downside of this is that if the user decides not to continue, then that number is "lost" and won't be reused unless you maintain a list of unallocated numbers somehow. Having an unused number may not be a problem in your application.

Either way you'll need an object that holds the next number to allocate, and the act of locking, reading and incrementing that number needs to be atomic (ideally controlled solely through some form of agent).

[BeeJay]

Snap. I was formulating a similar reply, but this time remembered to check in case someone else had replied in the interim. With regards to holes in the numbering, auditors seem to be the ones who are most likely to complain about holes in the numbering, but it's often the easiest approach for reducing contention in a high-usage system as that transaction can be nice and quick versus including it in the transaction that's doing the update. For example, you want to leave the call to get the number as late as possible, so that the "singleton" is locked for the shortest possible time, but you do want to get the number prior to setting any inversed references where that customer number is used as a key to avoid double inverse maintenance.

If there's no audit requirement for the number range to be contiguous then it makes the decision easier.

Cheers,
BeeJay.

[ghosttie]

Another option is using the object's Instance ID as its unique identifier - that way JADE does the work for you

[murray]

Another option is using the object's Instance ID as its unique identifier - that way JADE does the work for you

I would recommend that you don't use the OIDs for your application level data, unless you are sure of what you are doing.
You have no control over the value of the OID, for example: if you delete and reload an object it will have a new OID value.
Also, if you use the instance ID and have several subclasses you may well encounter collisions in instance ID values.
Omash, you should be aware of this if any other classes will depend upon the OID value as a foreign key.

[murray]

Hi Omash,

You could also have a look at System Sequence Numbers (introduced in 6.03.05)...

System sequence numbers enable applications in your JADE environment to have a series of consecutive unique numbers without requiring the use of object locks to ensure that the numbers are unique.

System::createSystemSequenceNumber()
System::getSystemSequenceNumberNext()

The documentation is not in the original Jade 6.03 manuals. It is in the later release notes and Jade 7 manuals.

The downside is that you have to initialise the starting number when the system starts up (it is not persistent).
This made it a problem for one case where I would have liked to have used this feature to rework some old code.

[M45HY]

Hi Guys,

Wow! Thank you for all of the replies. The way our system allocates a number is that once a user has keyed in information and then submits the form, validation is carried out on the neccessary fields and if there is something that the system does not like, it outputs an error message otherwise it will that try to create the record. Once the system has validated the data, I tell the system to check if the number, which is generated by ourselves, is available or not. If the number is available, then the system would use that number else the system will look for the next avaiable number.

I did think about creating a DynaDictionary with the information in and then processing it one-by-one but I wasn't sure if this would slow the system down as well as whether this was the best solution or not. In regards to Murray's statement, our company has not been upgraded to 6.03 yet ( ) but we are planning to do so within the next couple of weeks, hopefully when my workload has decreased ( ).

Is there anymore enlightenment on anything that I could do or would if have to use one of allistar's intriguing ideas? I more than happy to do either.

Thank you all,
Omash

[JohnP]

Conceptually, the part where the number is allocated needs to be single-threaded. This includes from checking the next available number to persisting the newly-allocated number. This would normally take place after validation is completed successfully.

[M45HY]

Hi JohnP,

That is exactly what the system does. It tries to find the next available number only if the validation of the form is successful. But it's the fact that when 2+ users submit a form at the same time, the coding that checks and gets the next available number (once validation is successful) also runs at the same time; returning the exact same number in both instances.

Omash

[murray]

That's why you need the single-threading that JohnP mentioned. Use exclusive locks to control access to the object that stores/generates the allocated numbers. If two competing processes are both obtaining a new number only one can obtain an exclusive lock on it at any one time. One process will obtain an exclusive lock first. The other process must wait until the lock is released when the first process commits its updates.