Inserting in a Custom table in an Fm via Parallel processing

[Former Member]

Hi,

I have a requirement wherein i am inserting certain data in a custom table throgh a Function module which has been processed through parallel processing. So do i need to use locking for custom table because many session will try to insert data in that table? The data will be different in each session.Tried searching it in Wiki but could not find related document. It will be helpful if anyone could give me useful links or suggestion.

Thanks.

[Former Member]

Hi,

I have a requirement wherein i am inserting certain data in a custom table throgh a Function module which has been processed through parallel processing. So do i need to use locking for custom table because many session will try to insert data in that table? The data will be different in each session.Tried searching it in Wiki but could not find related document. It will be helpful if anyone could give me useful links or suggestion.

Thanks.

[Former Member]

Hi Experts,

Any inputs?

[Former Member]

not really performance question,

yes you should use an enqueue for locking, and you must set it with all available key. Other parallel processes can also insert different data. But just in case, if the same key comes again, then the enqueue would not allow the duplicate insert.

Siegfried

[matt]

>

> not really performance question,
> 
> Siegfried

Moved to ABAP General.

[Former Member]

Hi,

I would wait for all parallel processes to finish and then commit in DB all results.

Technically, it means the use of call funtion keyword performing XXXXX on end of task.

In this perform you are retrieving a result table (with keyword receive results from function) and then append lines in a global table.

When all processes are finished, commit everything in DB.

[Former Member]

Hi Mathieu,

But what if i insert during the processing instead in the recieve statement. Won't t be one and same thing?

Thanks.

[Former Member]

Hi asagraw1,

My point was to insert after the receiving statement.

In the receiving perform you are just doing "APPEND ALL LINES OF et_results TO gt_results". So all processes will append results in a global table.

And when they are all finished, you are doing a single insert from this global table.

With this you avoid lock problems as you are doing a single database access (and you don't loose in performance as a single DB access is really efficient).

Regards,

Mathieu.

[AnjaneyaBhardwaj]

Hi ,

I assume you know

->about enqueue and dequeue process

-> The types of FM used for update

-> The update strategies are know to you .

Read more documents on update strategis to find when the lock gets released and what type of update you want asynchronus or synchronus ? depending on that you can decide how the locking mechannism should work ...if your ultimate aim is to update the table asynchronus update will work ..however you want further processing only if the the data has been updated go for synchronus ....

[christian_wohlfahrt]

Hi,

of course locking is in general the correct way, but if you are going for best performance in this special case... my proposal is different:

- you only do inserts (no update, no delete)

- your data is unique (no double keys)

-> just do inserts (with commit) and skip locking, there can't be any lock-situation for this scenario.

Of course it's different in case of updates or complex booking scenarios...

Regards,

Christian