> > I just want to point out that there is a world of difference between
> > multi-threading and orchestrated multi-tasking. With COM, multiple > > instances of a process can run concurrently, true, and it's a good > > thing, but there is no orchestration, i.e. no "dispatcher" to launch, > > monitor, track and account for async tasks as is required of a > > multi-tasking application. > > > > Thanks Bill but not sure I understand the difference and when > to use each. > > Let's say I am building the server side of a client/server. > Its prime purpose is to run SQL statements and return the > results. However sometimes the clients will be sending data > updates so some table/record locking will then be necessary. > In this example would I need multi-threading or orchestrated > multi-tasking? I'd go with stronger multi-threading. That is, have incoming queries check for locked resources and either wait and try again or return a "busy, try again" message. I know it's not really this simple, nothing about client/server apps is simple, but the point is that if you go the other way and build a server-side manager to receive query and update requests and then handle all possible conditions, you'll be faced with a much more costly and difficult undertaking (e.g. queuing gets involved). Sometimes that's what the hand calls for, but I'd avoid it without a fat budget. I think you said you're using VFP on the server side, I guess with WestWind/AFP/ASP/FOXISAPI. I'm only experienced with the AFP approach, but my understanding is that it's basically the same as ASP except with AFP you run VFP "scripts" submitted to the server that will be run by AFP/VFP on the server (which is a great thing!). I think WestWind is basically using FOXISAPI (sp?), but all of them basically interface with IIS, who receives incoming HTML (from POST) and hands it off to the specified processor, which does it's thing and returns HTML to IIS which then sends it back to the sender's IP. It's basically a one-shot, in and out thing, versus conversational mode, such as you could have with a multi-tasking transactions manager. The other word used to describe this difference is "stateless", which basically says you can't pass anything from one incoming transaction to another. If I'm in your ballpark <s>, there is a trick that might help: have your incoming update transactions acquire a global lock when it's started, and then free the lock when it's done. Then, have your incoming query processor test for this lock before running a query, and going into a short wait/try-again or return a "busy, try again" message. Because timing is so sensitive here I wouldn't try using a file's existence or contents for this lock (file system is too slow), but rather a server side global 'thing' in memory. Sorry I don't a solid suggestion for exactly what lock to acquire in this case, but maybe someone else will - and that is if any of this is in your ballpark at all. Carrying on a little more: as you can see, that's a brute force approach that renders complete lockouts while updates are being performed. You could get more specific in cases where simple record-level lockouts are involved, but I'd at least try the global lock first and by keeping records of lockout occurrences, tune from there. I'm combining two bodies of knowledge here. On mainframes there are such global resources that can be acquired for this purpose, and I've used them in cases like this, but I'm not aware of the specific Windows counterpart, I just know it has to be there somewhere. Bill > Cheers, > Nick _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
