Can somebody tell me where OI stores the information about which rows are locked by the current user? Have a feeling it's been discussed, but it's hard to find.

- Oystein -

They're stored in RAM on the server. Depends on whether you're using NLM/Service or plain network drivers as to where.

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezzatura,

That's not what I thought I read. Crossed memory circuit wires. I gather the app can't check which rows etc are locked then?

- Oystein -

Not in any way that can be defined as straightforward. (Can you see where this is going? ). What network product is in use?

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezzatura,

I wasn't thinking of a particular network product, but I understand now it's relevant.

I need to implement some programmatic locking in my latest app. I think I already have related programming (read, savewarn, etc) present in all the relevant places, and now I'm in the process of putting in the lock and unlock statements. If there was a table or list of locks somewhere accessible to my programming, the latter might consult the former to be more certain it got the locking right.

I assume I might extend the app myself with a table where the programming maintains info on locking, but that would defeat the purpose of my need for such a table.

Thanks.

I might be back with really basic questions about locking when I get down to the nitty gritty of the implementation.

- Oystein -

OK for now you'll just have to go with whether the lock is yours or someone elses. It is possible to do the maintenance of tables yourself detailing these things but as you say it is a little duplicating and prone to erroneous results if crashes occur. We look forward to the queries!

The Sprezzatura Group

World Leaders in all things RevSoft

Oystein,

Just to let you know…

Do NOT count on an "MFS" when monitoring locking and unlocking. Not all locking and unlocking go thru the "MFS" routines.

Richard,

Thanks. I hadn't even thought of using an MFS - yet. I do think I've located all the places where I have to do locking/unlocking. So I hope I won't need monitoring.

- Oystein -

Can you cite an example?

Sprezzatura et al,

I'm utterly confused about locking.

We have some clients with multi-user versions of our apps. Only one of them has a network produkt - the Revelation NT Service. None of them have very many users. 2-4 users are typical.

We seriously thought we'd given them apps with locking in place. But now I've started doubting.

If we did give them apps without locking, there might be explanations they haven't complained. Many of them have one user doing data entry while the others just search and browse. The ones who do have more than one person entering data often will have people working on the same tables but on different records.

The apps they've got are developed in OI16. We use the standard built-in functionality of table-bound forms. The forms have the following settings for locking: Lock for Update, and Ignore Self Locks. Shouldn't that be enough for locking to work?

We're now in the process of deploying a new app developed in OI32. In this new app I have included some of our own read/write/savewarn/etc programming, but much of the standard stuff is still in place. E.g, rows are read in with the normal READ event.

Now we did some experiments to see if locking works in the new app, and it turns out doesn't. Two users can open the same row without any message about rows being locked by other users appearing.

Also we are confused by what happens if two users open, change and save the same row. Both users get their changes stored on a field by field basis. If they change the same field, obviously only the last user saving gets his version saved, but where they change different fields, both users' changes are stored. We thought the stored row would reflect only what the last user saving had in his form before saving.

Now enlighten me. You may laugh first, but explanations next, please. If it's all described in some tech article I can read that.

- Oystein -

OK you should be getting locking. Test at it's simplest by opening records in the system editor and seeing if you get error messages. The update stuff is because the form update logic doesn't actually write @Record - it does it on a field by field basis - this is why you can ignore self locks and have sub forms update different parts of the row.

Cool huh?

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezzatura,

OK you should be getting locking. Test at it's simplest by opening records in the system editor and seeing if you get error messages.

I'm at home now - in a strictly single-user environment.

But I'll try first thing at work tomorrow morning.

(Or second thing. Coffee first.)

I forgot to mention we also tested the 16-bit app, with the same results.

Is there a trivial setting somewhere I've overlooked? In Database Manager???

The update stuff is because the form update logic doesn't actually write @Record - it does it on a field by field basis - this is why you can ignore self locks and have sub forms update different parts of the row. Cool huh?

Cool indeed. But my experience with sub forms have been that fields not in the form are written back empty. Although I guess my scenario was quite different from the one you think of.

- Oystein -

Sprezzatura,

Test at it's simplest by opening records in the system editor and seeing if you get error messages

What's the next simplest alternative? I didn't think of it when I replied last night, but you see we haven't got any multi-user developer system. (We are two guys on the project, but I'm the one who really does the development work. There's never been a reason to acquire a second license.)

- Oystein -

System editor should be able to be used from a runtime.

The Sprezzatura Group

World Leaders in all things RevSoft

I can not cite an example. I read it from the Knowledge base "Modifying Filing System" (mfs.pdf)…

1) Bottom of page 46 mentions "…and only if necessary – is the lock call passed through to the MFS." (Probably only if the lock fails).

2) Top of page 47 "As a result, not all lock calls can be trapped at the MFS level. (Again probably only if the lock fails).

3) Middle of page 47 "By executing an R/BASIC LOCK statement, the local lock table will be update property, A direct call to the filing system will not pass through the R/BASIC interpreter, and the local lock table will not be aware of locks made in this way; coordination with locally held semaphores will not be possible."

4) Middle of page 47 "The same is true of unlock calls. If the system can resolve an unlock call by referencing only the local lock table, it will do so. In these cases, as with the lock calls, the MFS will never receive the unlock call."

Sprezzatura,

Thanks.

- Oystein -

OK, but I don't think those references imply your conclusion. Let me try to explain:

] 1) Bottom of page 46 mentions "…and only if necessary – is the lock call passed through to the MFS." (Probably only if the lock fails).

The documentation goes on to explain about locks set by the workstation and reported by STATUS(). The only locks whose status can be correctly resolved at the workstation level are those set by the workstation doing the checking. This would be a situation where the workstation has a lock call for the same item twice in a row. Since the workstation previously set the lock, nobody else can have unlocked it (only the setter is allowed to unlock). By consulting the local lock table, the conclusion that the record is already locked locally can be made.

It is important to note here that whether the lock call got passed to the MFS or not, we know the lock was already set by the current workstation. Furthermore, the previous time it was set, it went through the MFS, so any code in the MFS to monitor locks would still be in place. What would NOT work would be a count of how many times the lock was set since the last time the lock was not set.

] 2) Top of page 47 "As a result, not all lock calls can be trapped at the MFS level. (Again probably only if the lock fails).

But what we're really interested in are not all lock calls but all lock calls that count.

] 4) Middle of page 47 "The same is true of unlock calls. If the system can resolve an unlock call by referencing only the local lock table, it will do so. In these cases, as with the lock calls, the MFS will never receive the unlock call."

Again, the workstation can only be certain about locks in its own control. This means locks set by it. If the program makes an unlock call to unlock a record that is not locked by the current workstation, this call need not go to the MFS. There is no information that needs to change on the server. If there is a lock set by this workstation on the server, it MUST be communicated to the server and hence must go through the MFS.

So again, the only unlock calls that matter for monitoring lock status, do go through the MFS.

But there's more in the documentation that you didn't quote. Using a record lock as the example, the filename and record name are not actually passed to the server to manage the lock. A token is created by using a hashing algorithm to create an 8-byte semaphore. It's this semaphore that is actually handled by the server. The result of this scheme is that two keys could hash to the same semaphore.

I assume that if these two keys represent locks both set by the local workstation, the conflict is arbitrated locally, and both locks are allowed to be set. However, if two different workstation attempt a lock on different keys that hash to the same semaphore, the second lock attempt will fail even though the record being locked is a differnt one. Even in this rare circumstance, monitoring lock/unlock calls that make it to the MFS are sufficient to track multi-user lock activity.

Additional handling of UNLOCK ALL calls must be made, of course.

I should have mentioned that the semaphore set by the BFS is available to the MFS (returned on lock/unlock calls). This semaphore can be used to detect situations where multiple keys hash to the same semaphore.

Sprezzatura,

System editor should be able to be used from a runtime.

For the benefit of others - here's how to start System Editor of a runtime system:

- Start the app

- Start System Editor (i.e, DWB.EXE) via a shortcut with command line parameters /AP=appname /UN=username /PW=password.

Is this docced (except here in the discussions)? Ira?

(There is a help article "Programmatically Starting the System Editor" which describes how to start System Editor from a running app, but that is something different.)

…you should be getting locking. Test at it's simplest by opening records in the system editor and seeing if you get error messages.

Our server runs Linux and Samba. I got the local network guys to look at the problem and it turned out the record locking capabilities of Samba have been off. I didn't know there was something outside of OI involved in locking. I know now.

After Samba record locking now have been set on, locking in OI seems to work, except I have some programming to do in the new app where not everything is done through normal READ and WRITE events. There will be trivial questions coming up very soon.

- Oystein -

View this thread on the forum...