topic Re: Custom Table Lock in Application Development and Automation Discussions

Custom Table Lock

abapdeveloper20 — Wed, 16 Sep 2009 07:01:32 GMT

Hi All,

In a program i'm inserting set of records into a Z-table. (5 fields - All primary keys)

I want to use table lock on the z-table , insert the records and unlock the z-table.

But what if my program is scheduled in background with different variants (lets say 5 jobs), each job will try to update the Z-table.

In such case , lets say job1 locks the table and updating 100000 entries to the z-table.

Meanwhile job2 want to update 5 entries to the Z-table tries to lock the table... in this case Job2 runs successfully or not??

Whether lock and unlock is necessary in this situation.

Any inputs.??

Re: Custom Table Lock

Former Member — Wed, 16 Sep 2009 07:06:49 GMT

Hi,

During such cases you need to have check on Job Run.

Suppose like when you run a particular job if it is failed you need to run the job again after some time. This we can do in programming using some standard function module.

As you said the job will definitely fail as the table is locked for updating.

Regards

Pavan

Re: Custom Table Lock

former_member404244 — Wed, 16 Sep 2009 07:16:33 GMT

Hi,

Job2 won't run successfully as job1 is not yet completed and the table is locked..so u will get Foreign_lock exceptrion in job2.

Regards.,

Nagaraj

Re: Custom Table Lock

Former Member — Wed, 16 Sep 2009 07:20:53 GMT

Job2 wont run successfully during the execution of the Job1 due to lock created by Job1.

You can do onething, give particular time to execute Job1 and give later particular time to execute Job2 and on and on......

This will solve ur problem.

Re: Custom Table Lock

abapdeveloper20 — Wed, 16 Sep 2009 07:27:57 GMT

Hi all,

What happens if completely ignore the Lock and Unlock of Z-table and go with only inserting entries into that table??

Re: Custom Table Lock

abapdeveloper20 — Wed, 16 Sep 2009 08:23:42 GMT

Any inputs???

Re: Custom Table Lock

Former Member — Wed, 16 Sep 2009 09:09:12 GMT

Hi Lakshmiraj,

Generally, when updating a lot of entries in a table, we try to lock table line per line (in order not to block other transaction also updating this table...).

But if you decide to lock the whole table, it is a bit dangerous to parallelize the update of the table, since the first job will successfully lock the table but will prevent the other jobs to lock it and then to update it!

So I recommand you to split updating of this table between your different jobs by the first keys of your table, let say, only the first field. For the 1st job you will have to update all entries with 1st key field in range 0000 to 1000, 2nd job 1000 to 3000, ...

Like that you can lock your table only on the first key field (via a lock object created in SE11) and all jobs should run correctly.

Another thing : if your program is the only program / transaction /... which updates your table, lock object is not necessary. Lock only serves to prevent database inconsistency after 2 programs have updated the same line in an incorrect order...

Hope it will be clearer!

Best regards,

Samuel