TRY CATCH Block - Best Design

[Former Member]

Hi,

I have a requirement where the database operation modify should take place, ONLY when there is no existing locks on the underlyining table...

I came with following

do

TRY.

Modify DBTAB

EXIT.

CATCH cx_root.

If sy-index > 10000

EXIT.

else.

wait up to 5 seconds.

Endif.

ENDTRY.

enddo.

Tries to Modify . If there is a exception(table is locked) it waits for 5 secs and reexecutes. Once execution is successful, the loop Exits....

Is this the best way to put something like this ina TRY CATCH Block

[marcelo_ramos]

Hi,

I think it's a best way to do this !

Simple and very safe !

Regards.

Marcelo Ramos

[Former Member]

Thanks.....

[uwe_schieferstein]

Hello Anand

I doubt whether Marcelo Ramos is taking your question seriously.

Think of the worst-case scenario: it may really take 10000 times before the DB update takes places. Since you are waiting 5 seconds every times it may take 50'000 seconds (almost 14h !!!) before the update of a single DB record takes place.

Sorry, but this is pure nonsense.

Instead, search for the lock object of the DB table and try to set the lock yourself. If you cannot set the lock it does not really make sense to wait or repeat the step because you have absolutely no idea how long this lock will persist.

Procedure:

1. Lock DB entry yourself.
2. If succesful, update DB table.
3. If unsuccessful, skip record.
4. Unlock DB entry.

Finally, the TRY...ENDTRY block is really useless in this situation.

Regards

Uwe

[Former Member]

Hello Uwe,

Thanks for updating this thread.

Yes I agree with ur points. But in my case the 10000 is not much relevant because the other process that might lock the table dosent really lock it for a long time.

So this logic is bound to get a lock pretty soon.

The 10000 is just to prevent endless loop. Yes, but as u mentioned I dont need to do 10,000 (14 hrs wait). Probably 10-15 counts is enuf really. I am sure it will get a lock within 1-2 mins worst case.

I know u can do this with a Lock object by explicitly setting the lock.

Only thing is it might not be required in my case....

The TRY CATCH is there to prevent DUMP when trying to get lock.... Else the program will dump if no lock can be obtained.

Thanks again for ur comments.

Thanks

Anand

[RichHeilman]

<i>The TRY CATCH is there to prevent DUMP when trying to get lock.... Else the program will dump if no lock can be obtained.</i>

I don't think so, you will not get a dump at all regardless if the TRY CATCH is there or not. If the MODIFY is executed and there is no lock on the record, the system will update the record anyway. This is why it is important to apply the lock youself before modify in the table. You don't appear to be even attempting to apply a lock on the record. The TRY syntax will not catch anything to do with a lock on a database table.

Regards,

Rich Heilman

[Former Member]

Thanks again!!! I will use the design to apply explicit locks... Its eems to be the best option..

Thanks

Anand

[RichHeilman]

For example, you should be calling the function module which is associated with the lock object your your database table. So here the db table is ZTAB and the function module used to lock the record in the table is ENQUEUE_EZTAB. You pass the key fields to the this function module, if SY-SUBRC is return with 0, then you have achieved a lock. This is the proper way of locking records in SAP.

Regards,

Rich Heilman

[Former Member]

Rich,

If no lock can be obtained for a Modify...it does indeed throw CX_SY_OPEN_SQL_DB exception and dumps.

If I have a Catch CX_SY_OPEN_SQL_DB (or cx_root ), then atleast it dosent dump and I can catch this exception !!!!

So TRY CATCH does make a difference.

Thanks

Anand

[RichHeilman]

I have never seen anyone ever use a try..catch for a database lock and/or database update using the MODIFY statement, when calling the function module you need to be handling the exceptions being passed back, this will prevent it from dumping. If your program is dumping on the MODIFY statement, it is simply for some other reason which you would need to figure out. The fact that you are avoiding a dump when using the TRY has nothing to do with the the locking mechisum.

Regards,

Rich Heilman

Message was edited by:

Rich Heilman

[Former Member]

Ok Thanks I will use the ENQUE module. I really dont want to do something that is not the general way

[RichHeilman]

Here is some help. Notice that the EXCEPTIONS section is declared in the function call.

http://help.sap.com/saphelp_nw70/helpdata/en/af/22ab01dd0b11d1952000a0c929b3c3/frameset.htm

Regards,

Rich Heilman