Valence & record locking

[jet]

Our plan calls for a gradual integration of iSeries-based GUI programs into our existing application structure. One of the questions that has been raised, is how Valence will fit in with existing 5250 apps in regards to record locking.

We have done a little trial-and-error and determined that Valence can hold record locks if the program returns without setting on *INLR. The problem with that is that if the user starts multiple browser windows (which is inevitable), all of those browsers will use the same iSeries job. This presents a problem with our theory.

Are we missing something, or is this just the nature of the beast?

[richard.milone]

Hi jet,

The CGI jobs that run in the VALENCE10 server instance (those are the ones marked with function "PGM-QZSRCGI") can handle any request from any Valence program at any time, they're not assigned by the Apache HTTP server to handle just one specific user session. For example, when a user clicks on the Valence hello world example, the HTTP server will assign a CGI job to send the user the initial page. Then when the user hits the go button the HTTP server may assign a different CGI job to handle that request. Therefore you should set on LR after every request so you do not maintain locks on records. If you need to provide a logical locking mechanism for open master files, orders, etc. there are serveral ways to handle that. I'll have one of our developers here who's familiar with locking schemes to add some ideas to this thread.

[jet]

One of the alternative methods that we use is for the application to save an original copy of the table row and post it back to the server in addition to the changes. The server program compares the original row passed in from the client to the DB. If the two match, no change has occurred in the interim and it is safe to update the row.

Question: I can send the table row to the browser in JSON format. Is there any way to return it in JSON, or do I need to send individual columns?

[richard.milone]

The locking mechanism you describe is called "optimistic locking" and is a good way to provide locking for web applications. Are you getting your original record with a standard Ajax call? If so, your response comes back into a variable like response.responseText and the JSON is parsed with the eval statement. If you just save off the response.responseText variable, that will contain the whole JSON-formatted record. Then you could send that whole sting back as a POST variable, and prior to updating your record you could get the existing record from the DB again, do the toJSON formatting and compare. If its still exactly the same updating can proceed, otherwise send back an error or warning to the user. I've actually never tried that but I can't think of a reason it wouldn't work. Another alternative would be to store the JSON string into a session variable on the backend so you wouldn't have to send all that data to and from the browser, but the overall length of the JSON string would have to be 999 chars or less. See vvSecure_saveSessVar in the Valence RPG Toolkit doc.

[richard.milone]

jet,

Another type of optimistic locking is one that uses timestamps. If you store the full timestamp of the last time a record was updated, you could send that timestamp with the record to the front-end, then send that same timestamp back with the record update. Then, right before record update on the back-end, re-read the record and leave it locked until you interogate the timestamps. If they haven't changed, proceed with the update and reset the timestamp to the current time. If they have changed, send warning or error back to the user.