11 replies to this topic

[Vol Yip]

Does anyone know if the Read Lock logic works? In the SL function maintenance and in each file, there is a Read Lock logic and the description says:

Logic to be Performed if Record Lock is Encountered on File.

I tried to put a UMSG there and simulated a Lock situation. I.e.,

Terminal A open the file in C mode
Terminal B tries to open the file in C mode again with the LOCK logic written

However, it seems that system doesn't execute the logic, terminal B still stops and wait for terminal A to release the file.

Any clue?

[Tony White]

I've used lock logic in version 4 on AIX OK.

Usually in updates running under cron, where I want to just ignore the transaction if a record happens to be locked.

I usually use something like

IF @RETRYCOUNT = 10
SUPPRESS_RETRY()
ENDIF

Not sure why your UMSG isn't working - but you could try this and see if the lock releases after (say) 10 retries.

[Rob Donovan]

Hi,

Are you trying to use it on an Oracle file?? I dont think that will work.

We dont use Oracle here so I'm not sure, but maybe you could look at setting the Unix Env Var LOCKED_ROWS_RETURNED = Y , then maybe it will work, but I dont know for sure.

Rob D.

[Vol Yip]

Tony,

I tried your example but my system still doesn't work....

I am using NT and Oracle 8.1.6

Does this work for Oracle DB?

Thanks,

Vol

[Vol Yip]

It works after added the LOCKED_ROWS_RETURNED = Y, thanks

[Richard Bassett]

Be aware that if you do not allow the database server to wait for locks you will defeat the database deadlock detection mechanisms.

Just so you know.

[Arnold Mulder]

Vol ...

Carefull turning this parameter on. In my testing with this parameter turned on, the lock logic would be performed, but for all other locks with no lock logic pro 4 would not wait and retry the requested read.

In the area's where we required the lock logic to be performed with Oracle files we inserted our own SQL command with the no wait option, and then used the lock logic to control the behavior on a file by file basis.

[Gregg Barr]

Does anyone know if Glovia recommends this? We have had record lock problems since day one. If this would solve that problem and not create new, more deadly problems, I would make this change in a heartbeat.

[Vol Yip]

I do not recommend to enable this especially in GLOVIA. As Arnold has mentioned, once this is enabled, all lock mechanism will be destroyed if the LOCK logic is not set. GLOVIA definitely not using this logic. That will cause serious application problem as data integrity will have problem. Think of the situation that if a file is locked and the mechanism says 'ignore the lock and process', then other files will be updated but this one.

[Gregg Barr]

How is this for conflicting information? I received this from Glovia tech support when I created a case asking about the LOCKED_ROWS_RETURNED setting.

'I have confirmed with one of the PRO-IV person here at Glovia. It should be fine to set LOCKED_ROWS_RETURNED=Y in the pro4.ini file. If you have further question regarding to this case, you can respond to this email or call at (310) XXX-XXXX.'

Now I don't know whom to believe. My experience with Glovia support makes me doubt they have put much thought into the answer and just wanted to close the case quickly. If anyone from Glovia (Cory?) is reading this can they give me the definitive answer?

Thanks

[Vol Yip]

Gregg,

This is purely my personal comment on the usage of LOCKED_ROW_RETURNED. Glovia tech support shall be the offical source for the support. My comment has nothing to do for GLOVIA but I am based on the PRO-IV mechanism to justify my comment. BTW, the reason for my comment will be:

1) If the locked function is not a screen function, then based on the behaviour of the LOCKED_ROW_RETURNED, the function still does a wait. the situation doesn't improved. The worst is, now, the DEADLOCK mechanism is destroyed and Oracle will not issue a DEADLOCK error. (and, therefore, no ROLLBACK) The two locked functions will be waited indefinitely. User has to issue an explict break to break anyone of the locked functions. However, once the user breaks one of the deadlocked function, it is very difficult to tell if the other function will be updated correctly or not.

2) If the locked function is a screen, then, yes, the behaviour will give user a chance to input another input field to avoid a lock.

Vol

[Cory Gaw]

Gregg! I knew i could feel my ears burning for a reason.
Well, i don't use the file lock logic within SL, but i'll give you my understanding of the functionality.

If you're using it in a type 'U' or 'R' function, SL's not going to exit that logic ID and any FLD(xxx) or DSEL logic will be ignored unless you've added the SUPPRESS_RETRY(). If you do this, and don't specify a fld, it'll just drop out to the rtn_fld. You can track the number of times SL attempts to access the table with the @RETRYCOUNT and then issue the suppress once you're ready to give up, and fall out to your error routine.

Enabling 'LOCKED_ROWS_RETURNED' to the environment file, results in the 'NO WAIT' keyword being added to the sql select statement, thereby enabling Oracle to proceed.
If you suppress_retry in an 'S' function, it should attempt the write, and then release the lock, returning you to FLD for a new value. However, if FLD is a display only, it will loop again for retry.
If you're on a syspass in a paging screen when the lock hits, it should drop you out to the SEQ (first field, right?)
Now, my understanding of the processing is that you will not require 'lock logic' for all tables, as a result of enabling the 'locked rows returned' environment variable. SL's default logic should manage this. For the official documentation on this functionality, please refer to PRO-IV logic documentation for 'default behaviour' in the lock read access logic 'Using Logic, Chapter 2.
I hope this is helpful.