Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
MTS - Usability
Message
From
07/10/1998 11:48:04
Eric Barnett
Barnett Solutions Group, Inc
Sonoma, California, United States
 
General information
Forum:
Visual FoxPro
Category:
Internet applications
Title:
Miscellaneous
Thread ID:
00128652
Message ID:
00144630
Views:
24
Gee, am I glad to find this thread...

I've created a VFP middle-tier COM component that models business objects and allows for rules, key-based access, etc. After some reasonable testing from VFP I stuck it in ASP using Server.Createobject/CreateObject. Performance was great, until I tried simultaneuous access:

After adding the second or third client, ASP generated an ASP 0107: Stack Overflow, and then told me "the data being processed is over the allowed limit". After reading everything I could find on the subject (trying to reduce the VFP stack size, etc.) I subscribed here and saw your description on this "blocking problem". Seems like a good possibility.

The thing is that whether you like it or not, it seems that in IIS 4.0/ASP with Transaction Server installed mtx.exe (Transaction Server Explorer) hosts all of the threads that ASP spawns whether or not you have the package (DLL) registered with Transaction Server. Based on what you are telling me, the method calls should just be serialized, which is a big scalabilty drag but shouldn't break the app. Yet ASP seems to break!

So based on what you are telling me, I have 3 choices:

1) Figure out a way to serialize the method calls.
2) Use out of process single-use EXE's (which will of course spawn entirely ne threads for each use). What is the overhead involved here? I know you can configure ASP to use out-of-proc components but I haven't heard much about how well it works.
3) Give up and wait for Service Pack 1. Any idea how long until release?

I'd appreciate any further light you could shed on this subject.

Thanks.

Eric Shaneson

>>>should conform to Single Threaded Apartment model threading. VFP6 actually
>>>does conform to this model, but has internal blocking to prevent simultaneous
>>>operation of method/property access.
>>
>>WOw... glad to know someone understands this.
>
>Well, I've been boning up on COM for the last couple of years as part of
>what makes Web Connection's COM interfaces tick <s>... There are a few
>decent books out there. If you are interested in this stuff, I highly
>suggest you start subscribing to Visual Basic Programmer's Journal. One
>of the best sources for all issues COM...
>
>>So, if they can block this an allow sumultaneous 'psuedothread' is MTS still not needed?
>
>Whether you use MTS or not is not going to fix the problem, because regardless
>of how you access that InProcess COM component it will block. In MTS it's
>just another process that's blocking rather than your own calling process.
>MTS is really a proxy that takes an incoming COM method call and routes it
>to the actual object.
>
>The only way you can get around the blocking issue is to not use InProc
>servers. Single Use EXE files will give full simultaneous processing. If
>handled smartly you can achieve good scalability with this model, which
>is essentially what Web Connection does with COM backend servers.
>
>>
>>As you said, it seems to be the MTS is really only needed when doing homogeneous transactions or complex multi-object transactions?
>>
>>However, isn't another advantage to MTS the role based security?
>>
>
>Yes. There are a number of features of MTS that are nice, but you have to
>ask yourself whether it's worth the overhead, lack of scalability and extra
>development effort to achieve them. Role based security simplifies security
>adminstration, but a proper security layout will solve that problem just
>as well - it just means you have to understand the security model, which
>is what MTS aims at eliminating.
>
>A lot of features in MTS are that way - just about anything MTS does you
>can do standalone. It'll just be more work. But even if it did work with
>VFP as expected you'd still pay for it with overhead and potentially
>complex development scenarios.
>
>>Hmm... what to do... we are told three tier... but still deciding on how the middle will work. Is it possible to create a scalable 3-tier in VFP without using MTS or any other middleware?
>
>MTS isn't a tier <s>. It's simply a hosting mechanism for x-tier components.
>MTS isn't a requirement for multi-tier applications. The jest of 3 tier is
>to isolate user interface, business rules and database. The key to make this
>work is solid class design. Heck you can do proper three-tier development all
>in VFP as long as you design it right. If properly designed the tiers can be
>broken apart into separate COM objects (except maybe the UI layer).
>
>BTW, I've been harking on MTS quite a bit in this thread. The reason for this
>is simple. All the scenarios, examples and even newsgroup posts I've seen have
>yet to show me *something* that MTS does that makes it worthwhile technology.
>
>The reason many people implement MTS now is not because they need it, but
>because they *think* they need it and because MS says it's the right thing
>to do. I don't doubt MTS will eventually fill the needs of Enterprise
>computing, but that time is certainly not now at least not yet.
>
>Regards,
Eric Shaneson
Cutting Edge Consulting
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform