MultiUser Environment, Best Practices

[NasibKalsi]

Dear All:

I wish to collect some ideologies and thoughts regarding MultiUser environment. What are the best parctices in your openion for rlock(), use file again shared nomodify, etc. ?

Regards


Nasib Kalsi

 

[Mike Lewis]

Nasib,

This is rather vague question on a very big subject. It's especially difficult for us to answer given that we don't know how much you already know.

It would be better if you start by reading up on it yourself, and coming back when you have some specific questions. I suggest start with the Help topic "Programming for Shared Access". That should give you a good starting point.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

A agree with what Mike says. Also there is no best way and all these possibilities of locking manually vs automatic only, buffering or not.

Andy Kramek has an article about the subject of locking and buffering. He opts for optimistic table buffering as the best option, but it depends on the case.

The first thing to learn is, he buffering option of FoxPro mixes two things into one: Locking and buffering are separate things. They are closely coupled, but are two things to consider separately. I agree wholly on Andy Krameks point of view [1] but one thing is more true than anything else: You can always use table buffering instead of row buffering and have more control about when to commit a single row, have more freedom to move around in the buffered table, than when doing row buffering only.

Also don't be lead to wrong ideas because of the terms optimistic and pessimistic, this has nothing to do with your overall view on life. Just read about the mere technical meaning of these things, they are all explained very well, and so you can decide by taking each single part into consideration. You can really make good use of a decision matrix about what best fits your need.

I can ttll you about experience, but it's not necessarily valid in your case. For example I made both bad and good experience with RLOCK and FLOCK: Good experience was usage of these for exclusive increment of an ID counter, bad experience with them was for locking out secondary users from editing. Either the locks weren't respected in parts of a larger network - which means due to bad syncing and forwarding on the OS level secondary users were able to edit locked records - on the other side locks persisted longer than they should even when you closed tables and used FLUSH FORCE, again bad syncing of the lock info on a file or part of it. But that really also depends on hardware and software settings. We nowadays know about the bad influence of OpLocks for one thing, but it surely is not the only thing, which can hit your theoretical plans.

So overall I got a bigger fan of not locking manually, but you may need it, if you need to only allow one change at one station at a time. A good example for that is lending books from a library. What you finally do does not only depend on how it should work theoretically and how it really should work theoretically, not only in your understanding, but also depends on how it work practically.

There really is no best practice here. There is your needs - and only you or your customer can tell that - and what practically works.

You can consider hoe the non FoxPro world works: Disconnected. If you go to web or the client server, you make a request, get a response and are then disconnected again, SQL Server work that way, Web Servers, too. So thinking in that direction is not wrong and if you do that, you would rather need to forget about the option to lock and reserve something. If you consider that restriction and still find a way to make your application work, it will be easier to later migrate to one of these technologies, when you will need to move away from FoxPro. It can make it harder to fulfill your needs, but it will also leave you with less options and make it easier to decide.

Bye, Olaf.

 

[Olaf Doschke]

I forgot to put in a link to what I marked with [1] in my previous post: Andy Krameks article about locking and buffering:

http://weblogs.foxite.com/andykramek/2005/10/18/buffering-and-locking-in-visual-foxpro-an-overview/

It's a good read on the topic. But it doesn't free you from reading the chapter Mike mentioned, which shows you all the basics and is a foundation to understand what Andy Kramek says:

http://msdn.microsoft.com/en-us/library/h6hhascz(v=vs.80).aspx

Bye, Olaf.

 

[JRB-Bldr]

I agree that this is a BIG topic with quite a few things to consider.

In addition to Olaf's link references you might want to do a Google search for: vfp mulituser

Many of the 'finds' offer their own ideas of things to take into consideration.

Good Luck,
JRB-Bldr

 

[NasibKalsi]

Mike: You have been so right. I am vague. My goal is to see how one develops multiuser application. I have been creating a special field MULTIUSER and put the name of the Station who uses it, then advise the others if they attempt to modify the same record. And a special button to clear all MULTIUSER in the event of crash. Along those lines.

One of the most important fact I wanted to resolve by this post but forgot was 'dataset corruption'. Dataset , even in the worst situation(tolerable) stay intact.

I will read your suggestion(s).


Olaf: Thanks for the overview, I enjoyed it. I will go over your suggestions and get back by next weekend.

JRB-Bldr: Thanks. I remember you writing something along these lines "I never open my tables for ReadWrite, unless I need to update". If it is you, would you please expand on that.



My Best


Nasib

 

[Olaf Doschke]

> I have been creating a special field MULTIUSER and put the name of the Station who uses it, then advise the others if they attempt to modify the same record.
> And a special button to clear all MULTIUSER in the event of crash. Along those lines.

Well, you can both say it's a good and a bad idea. For one: Theoretically this can be done by RLOCK or pessimisitc buffering, which even would take less code to implement it, users editing a record would lock it at the same time via pessimistiv buffering. On the other side: Taking into account my bad experience with RLOCKs, it's agood idea, even though you reimplent that feature this way. It's also portable and usable with SQL Server, for example. This way of soft locking by a mechanism your own app implements and observes, you can still override it administratively. But that's also a noncontrollable side effect, if another application starts working on the same data, it has to know and observe your self defined rule about the MULTIUSER field.

I would first test, if RLOCKs work well or pessimistic locking, and only if that fails in your specific LAN, would go a selfdefined route.

Bye, Olaf.

 

[Mike Lewis]

I have been creating a special field MULTIUSER and put the name of the Station who uses it, then advise the others if they attempt to modify the same record. And a special button to clear all MULTIUSER in the event of crash. Along those lines.

What you are trying to do is called "pessimistic locking". In a word, it means preventing two users from editing the same data at the same time (an over-simplification, but it will suffice). While your appoach might well work, the usual way of doing it is to use RLOCK() (or, in some cases, FLOCK()).

You might add those two functions to your reading list as you research the subject further.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

"I never open my tables for ReadWrite, unless I need to update".

I don't remember saying specifically that, but I do only open tables when needed and close them when not needed. That approach adds a small amount of time over-head to running the application, but it is generally very small.

If your application has an over-all menu and your users only go into a single menu choice at a time, then, in that situation, I only open the tables needed for that menu 'utility' and close them when the 'utility' closes as part of 'housekeeping'.

Also a challenge that I have encountered with clients is that, despite 'educating' them not to do so, users many times go home for the evening or weekend and leave application menu 'utilities' still running on their workstations.
In general that is not a problem, but if there needs to be data table maintenance run over-night or over-the-weekend on tables that those users have IN USE, problems occur when those tables cannot be accessed EXCLUSIVE - sure code can be written to skip those tables, but the periodic maintenance is then not performed as intended.

With that in mind, I often write my client 'utilities' such that they open Cursor 'copies' of the 'real' data tables for reference purposes, and then if, as a result of a utility operation (Data Entry/Modify/Delete/etc.), I will open the 'real' table for a short period of time and use the updated Cursor to perform the operation on those particular records after which I quickly close the 'real' table.

NOTE - That approach is not too different functionally than what would be used if you were using a MS SQL Server (or other) data 'backend'.

That is not necessarily the best approach for the best/quickest application performance, but it does minimize the likelihood of data table IN USE when negligent users (I encounter many at my clients) leave things running.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

That is not necessarily the best approach for the best/quickest application performance, but it does minimize the likelihood of data table IN USE when negligent users (I encounter many at my clients) leave things running.

This is a problem everyone encounters.

I had a client who was so tired of the weekly pack & reindex failing he solved it once and for all. He issued a personnel policy change: "Leaving an application open when you leave the office will result in termination."

The first time someone did it, they were fired.

Problem solved. Permanently.

Not many companies will do this, though. (And justifiably so!)

 

[Mike Lewis]

Gosh, Dan, that sounds harsh. And as you rightly say, it's not an option for most companies.

Better to do what I (and many other developers) do: give the admin user the ability to force any user out of the application - after a fair warning. That's easy to implement, serves the purpose, and doesn't risk the company losing an otherwise hard-working and able employee.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

As I said, he only had to do it once. ;-)

But yeah, all apps need a admin kill switch.

 

[Olaf Doschke]

An admin switch may be used selective to only cause the one app to shutdown, when you need maintainance of it, also during the day, but there are also other ways to solve the nightly shutdow, even without an admin kill switch built into the app. You can remotely shutdown pcs.

Computername="CLIENT1" && need to know a list of computer names or "." for the local machine.
oWMI=GetObject("winmgmts:{(Debug,RemoteShutdown)}//" + ComputerName + "/root/cimv2")

oComputers = oWMI.ExecQuery("Select * from Win32_OperatingSystem where Primary=true")
for each OpSys in oComputers
    ? opsys.csname
    *OpSys.Win32Shutdown(12) && 12 means force poweroff, there are other modes
endfor

You can let your app write their computer name into a table of active clients and use that list, getenv("Computername") is giving you your own computer name. Also I'm sure you can find out a list of computer names via WMI or something else, eg in VFP ANETRESOURCES. To be able to shutdown remote PCs you of course need admin rights, so this would run administrative on a server.

Last not least, program in a way a shutdown ends your app. Force poweroff will still force all processes to quit, but if not hanging during shutdown your app can end clean without open files or transactions. Take a look at Form.QueryUnload().

Bye, Olaf.

 

[Mike Lewis]

This is an interesting discussion, and we've raised some useful points. However, Nasib should keep in mind that it is not really central to his original question. He needs to focus on the basic issues of file and record locking, and exclusive vs shared use, before getting bogged down with the question of how to terminate users who haven't logged off.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

It's still in the broader question Nasib Kalsi had about "ideologies and thoughts regarding MultiUser environment". The problem to end users session is of course easier to cope with in a single user application.

Bye, Olaf.