Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Strange limitation on MTS objects?

Status
Not open for further replies.

sorin

Programmer
Sep 20, 2001
6
0
0
US
Hi,
I have this scenario (everything is vb6):
- The main program in an standard EXE that contain a MDI form with a button.
- each click on the button create a new form
- each form instantiate an ActiveX.Exe object (to simulate multiple threads)
- in each instance of the ActiveX.EXE I call an object (dll) that should do something. This dll can or cannot be installed on MTS. If is not installed on MTS, everything work fine; I can run as many instances of the ActiveX.EXE as I want (20+) and the dll will work for each instance. If the dll is installed into MTS I still can install any no of ActiveX.EXE as I want (20+) but the dll will work only for 8 of them in the same time. It seems that the other instances are frozen until some of the first 8 finish his job; then they begin to run but no more than 8 at a time.

In the end, this dll MUST run under MTS (will use transactions) and must run for around 50 instances simultan.

This limitation it's not dependent on the machine, I tried on diferent configurations and the limit is the same:8.

Any ideea?

Thank you,

Sorin
 
I'm assuming your DLL was written in VB?

If so, try switching the DLL over to C with the project marked as being multi-threaded (you may have to add code to prevent re-entrancy problems).

Otherwise, I think you've hit a limit of MTS.

Chip H.
 
I presume you'll have a client.exe/asp calling the activeX.exe.
Why not not put all the code in the dll and just call this?
This way I've had 718 simultaneous transactions.
Do you definatly need out-of-process for multiple thread spawns?

But keep trying cos I wrote some stuff for some EPOS tills which used ASP pages. I was gonna drop an OCX on but found I couldn't address the h/w of the tills. In the end I used an ActiveX.exe and this calls an MTS dll object with no problems or limitations... there were about 220 till units.

This was NT4 client (SP6), NT4 server (SP6) and SQL7.

Hope that helps any.
 
Hi,
Thank you for your answers.
To move to C is not a solution for me(my c level is not very good)
The transactions I use call an third party component and takes between 3 and 5 min to complete.
Those transactions are not generated by an asp page. there is a client on the same machine (the server) that instantiate this activex.exe.
From my latest test it seems that the combination MTS & third party component generate this limitation. It seems that the third party com stop the comunication for more than 8 instances when is instantiated by MTS.
Those are my opinion, but I'm open to any sugestions.

Thank you,

Sorin
 
Hi (Guest Paul from above)
I'd consider the objectives that the 3rd party com gives you and write an in-house solution.
This not only gives you full control but also avoids any licensing issues and possible limitations that you may be experiencing.

:¿)
 
There few things you have to do
1.) make sure vb project (dll) properties is set to retained in memory and threading model : apartment threaded
2.) tick the remote server files - for dll reside in MTS
3.) change the Dll base address to a unique value - pls refer get unique dll base address at 4.) at MTS console, increase the DTC log file from 1 MB to maximum
I've try this and it's work fine
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top