Question How To Run Daily Core Batch Without Record Lock Issue Even Application Up And Active User

[kalaiarasan]

How to run core batch (daily job) without record lock issue even application up and active user in the app.

for example: core job running in appserver in unix with 100 contract, in this, if one of the contract is being used by some other user in the same application then core batch getting error out with lock wait timeout of 1800 seconds expired (8812).

Please advice me to , how to overcome this issue

 

[GregTomkins]

Big complicated issue. Superficial answer: track down the FIND in the batch process that's encountering a lock, and change it to use NO-WAIT. Put it inside a loop with a small delay and keep trying until the lock disappears.

That's a band-aid solution though. IRL, we have 1000's of batch programs that run concurrent with 1000's of interactive users and we almost never use NO-WAIT.

Instead, the more proper approach is to keep transactions so small/short/fast that any locks are automatically cleared within a few milliseconds, in which case the runtime handles everything for you and you don't even have to know that it happened.

Bad code:

FIND thing EXCLUSIVE-LOCK.
FOR EACH other_thing EXCLUSIVE-LOCK:
  DO tons_of_stuff_that_takes_lots_of_locks.
END.

Better code:

DO TRANSACTION:
  FIND thing EXCLUSIVE-LOCK.
END.
FOR EACH other_thing EXCLUSIVE-LOCK:
  DO tons_of_stuff_that_takes_lots_of_locks.
END.

For this to work, though, your use of 'thing' has to allow for the possibility that the program fails for some reason during the processing of other _thing. The advantage of the 'bad code' approach is that the whole thing is atomic, so it's simpler, but so prone to lock problems that we generally avoid it.

 

[TomBascom]

Optimal solution: Fix the crappy code that is handling record locks so badly (see Greg's post).

Less optimal: Set the -lkwtmo startup parameter to something pretty short. Like 10 seconds.

Better version of Greg's post:

do for thing transaction:
  find thing exclusive-lock.
  thing.something = somevalue.
end.

The FOR block "strong scopes" the buffer to the block. This prevents the scope from being expanded to a wider block and keeps your locks and transactions under control. If you get compiler warnings or errors about this sort of code the compiler is really telling you that you have a problem elsewhere that needs to be fixed.

Only ever create, update or delete records within small, strong scoped blocks that contain no UI or any sort of potentially blocking statement. Feel free to use named buffers to make it easier to "smell" i.e. "define buffer upd_thing for thing." (which is the true meaning of "Hungarian Notation".

 

[GregTomkins]

that contain no UI or any sort of potentially blocking statement.

I forgot that code like this still exists, but we certainly *used to* have our fair share of it. But yeah, if you have code like this:

FIND thing EXCLUSIVE-LOCK.
UPDATE thing.field.

... ie. the user can go for lunch while the 'UPDATE' is blocking the UI ... well, nothing short of rewriting that code completely is really going to help. You need to do that anyway

 

[kalaiarasan]

So here what i understood that we can't update record when someone is already blocking it .hope i understood correctly. and is there anyway to overcome the situation like,if someone is blocking the record in UI and at the same-time core batch is running in back-end trying to update the same record. what are the available way to complete the batch with record updates or no way to do it . Note: I don't want to update anything on UI when batch running.
Can anyone help me to understand the way? how progress handle this situation.

 

[TomBascom]

The whole point of locking records and respecting transactions is to prevent the chaos that would result from allowing a program to update something that another program was in the middle of updating.

If you do not want the UI to update anything while the "core batch" is running then you need some method of communicating that to the UI and the UI needs to acknowledge and respect that. That would be an application design and architecture sort of decision - not a feature of OpenEdge. (In other words... Fix your crappy code...)

 

[kalaiarasan]

Thanks all and special thanks to TomBascom. Above assumption is not with respect to production only for lower region(other than production) because users was active in UI while batch is running.

 

[TomBascom]

One method to resolve that is to write a script that kicks them out and keeps them out while your batch is running.

 

[kalaiarasan]

This is my expectation at the time when lock wait timeout error because, on next day i can process same contract which left on last day . if possible can you guide me how to write a script in .p module ?.

 

[TomBascom]

Aside from the obvious observation that the system that you are coding for has some fairly significant problems with basic simple stuff like record locking and transaction scope I know very little about that system. Blindly writing a script to kick users out and keep them out would very likely cause more problems than it would cure. So far everything that you have posted strongly suggests that chaos reigns so maybe nobody would notice but I'd rather not make it any worse.

I think that you (and whoever else works on this system) would be much better served by taking a class in fundamental (Progress 4gl) programming. Pay special attention to the bits about scope, record locks and transactions.

 

[Rob Fitzpatrick]

There is a pretty good discussion of transactions, record scope, transaction scope, locking strategies etc. in the OpenEdge documentation. I suggest you start there.

 

[kalaiarasan]

Yes right! This should be an application design and architecture problem when our application started and it was placed almost more than 20 years old with million of record. However our core batch was running in production with appl. down(users not be active) so it won't be a problem in locking issue(only production) as it is an internal application. anyway I am beginner nearly 2 years of experience in progress4gl and started to go through the topic again which you were suggested. thankyou! and i just started this conversation that trying to understand an application that why this much of 'bad code' code is in placed .
as it might be because of internal application.