Object Lock Issues

[Paul]

Hi,

We’re still neophytes in your world but one of the things we’re have a hard time understanding and dealing with are the object locks being created and when those locks are released and whether or not we can gain finer control. For instance:


I created a test user account on our AS/400 and in Valence Administration which I logged in with just to make sure a grid was limited as expected. I logged out and tried to delete the account from the AS/400 but it was being held by the VALENCE22 job under the QTMHTTP user. I’ve been trying to shut down the server to release the lock but the server won’t shut down. I’ve logged out of all Valence sessions and closed by browser but the server is still running. In WRKACTJOBS I have VALENCE22 jobs still showing under both the test account I'm trying to delete and the real account I'm using for the application. And in the HTTP administrator the server status is “Stopping”. It’s been 20 minutes. This is the second time this has happened where the server would not shut down and one of the users had a file locked. I had to end the jobs manually. See the next issue.

I had a logical file I created and after testing it in Valence I realized I forgot to include a column. When I tried to delete the logical so I could recreate it, it was still held by the VALENCE22 jobs running under the user I had logged in to Valence with even though I had logged out and closed the browser. I was able to release the lock by manually ending the job.


There have been numerous other instances similar to the latter where I was only able to release the lock by restarting the server. Can someone explain to us how the object locks work, how long they’re held after log out, and if possible any additional controls we can use to force locks to be released without restarting the server instance?

Thanks,
Paul

[richard.milone]

I think there might be some unique problem on your system. It's very suspicious that your http jobs will not shut down. I see some of them are in EVTW status, are you sure you don't have a debugging service job started on those? If that's the case they will not end until the service job (or service entry point if you're coming from RDP or RDi) is first released.

I'm not surprised that you can't delete a logical. You will definitely find that Valence leaves objects allocated. Leaving files allocated is a natural remnant of the Valence design methodology. Because the programs run in a named activation group the files will not be completely free until the server instance is ended, even if files are closed manually and lr is set on. This is the desired behavior because of performance reasons so that files don't need to be allocated between each stateless call. To guarantee there are no file locks, like before a backup, the Valence server instance should be ended. However, adding a record from Valence and then going to the database and deleting it should be possible. There should be no record level locks left.

Like I said, I think there might be some unique problem on your system. If you want we can get online tomorrow and have a closer look.

[Paul]

You’re absolutely right. I had a service entry point set both times the server wouldn’t shut down. I didn’t even think about it. Duh.

The allocation thing will definitely be somewhat inconvenient. If we’re in development mode we’ll need to be able to replace objects without having to restart the server since that would affect production apps. Do you find that most shops are running separate server instances for development as well as the normal separation of data and program libraries?

[richard.milone]

Yes, all shops we do development work for have separate live and dev instances and libraries. By the way, most of the time you can stop and start a Valence server instance without affecting users. I only rarely need to do it in a live instance but I just wanted to point out that it's possible. At worst they might get the "Valence has lost communication with the server" message for 30 seconds or so, but usually they won't even get that if it restarts fast enough.

[robert.swanson]

Hi Paul,

Just to throw in a couple more tidbits on this topic...

You should be sure you have the “Development instance” box checked in the “Settings” application for the Valence instance in which you’re making frequent program and file changes, otherwise you might find recent changes made to your programs aren’t taking effect (because the system is still using the original object that was moved into QRPLOBJ once you recompiled). This is explained in more detail in the Valence manual.

For your file object locking issue, you could also consider using a unique named activation group on your custom programs and then adding a RCLACTGRP(*ELIGIBLE) to the VVCALL program, but beware that you’ll likely take a significant performance hit doing this. Restarting the server when needed, as Richard suggested, is the approach we generally recommend.

Lastly, keep in mind you can quickly restart your valence instance in Valence 2.2 using the supplied “VVSTART” command (which, in essence, will issue a “STRTCPSVR SERVER(*HTTP) RESTART(*HTTP) HTTPSVR(VALENCE22)” command). This RESTART(*HTTP) approach works so quickly that in many cases the users won’t even notice anything happened.