Number Range Object vs. concurrent access, need sequence

Hi there,

-- short version --

1. there's a number range object

2. many users access it while working in the system

3. i need to ensure, that for a single database update consisting of many single record updates in a loop, the returned number object values are in a sequence (assumption: number_get_next-QUANTITY=1).

4. will a mutex suffice (performance impact is negligible) ?

4.b. if mutex is to be used, do I have to turn number buffering off ?

-- long version --

An external company designed an export interface, which logs changes in HCM module on the fly.

Internal table with changes is processed on a per row basis.

Let's assume the table looks as follows:

IT_CHANGES-INFTY - infotype
IT_CHANGES-MODE  - <i>nsert / [M]odify / [D]elete
IT_CHANGES-X     - some data

IT_CHANGES[1]: 0001/D/some_data1
IT_CHANGES[2]: 0001/I/some_data2
IT_CHANGES[3]: 0001/M/some_data3
IT_CHANGES[4]: 0002/D/some_data4

Now the interface works more less like this:

LOOP AT IT_CHANGES.
  PERFORM prepare_log_entry.
  PERFORM generate_unique_number.
  PERFORM insert_to_db.
ENDLOOP.

So basically What the interface does is take row 1, prepare log entry, generate unique record number(using number range), insert into Z* table, rinse and repeat.

Now there's a need to ensure, that all the entries with INFTY=0001 have their record numbers in a sequence.

Assuming per row internal table processing, and concurrency(many users can perform actions logged using the same number range object), it may happen, and it in fact did happen, that numbers were not in sequence.

The problem is I do not want to modify the interface to work with tables not rows, as it would require almost rewriting it from scratch (basically its composed of many subinterfaces, logging various activities).

I've came up with an idea, which I need a hand with, will this ensure numbers generated in a sequence:

LOCK_MUTEX.
LOOP AT IT_CHANGES.
  PERFORM prepare_log_entry.
  PERFORM generate_unique_number.
  PERFORM insert_to_db.
ENDLOOP.
UNLOCK_MUTEX.

I know, creating a mutex might is not an ellegant way to solve the issue(performance wise), but assuming there's about 100 log entries a day I think It would not have a significant performance impact.

Cheers,

Bart