This content has been marked as final. Show 6 replies
Hi user734005 and others,
and thanx (I should have used the phrase "client" instead of application/process/service)
Since this limit of 50 might be a subject to change, is it defined somewhere in some header-file or is it possible to retrieve it in runtime etc ?
Does anyone know why such limit exists ? Does anyone have a hunch if a change-request (i.e. don't have an explicit limit) would be considered by Oracle ?
I believe the actual limit is 50 outstanding calls for a given Tuxedo context. Since a client can be multi-contexted, it should be possible to have more than 50 outstanding calls within a single client.
As to why and how to get the number... For each outstanding call, Tuxedo maintains an internal handle in a table. The size of this table is set to TM_MAXHANDLES. Unfortunately this macro is not defined in a publicly published header file.
You can certainly raise an enhancement request, although I'd have to ask why you need more than 50 outstanding calls for a single context.
Oracle Tuxedo Chief Architect
unfortunately (or actually fortunately) we're just working with single threaded applications
The reason why we sometimes wanna have more than 50 outstanding requests is because of our semi-SOA-design-patterns that in some cases makes us wanna operate on any given amout of data in a generic way e.g. fetch information for every customer in list and because of performance you do want to do that parallell (instead of a sequence). Of cource this could be done with multi-threading but that's not how we do it (today)
To solve this problem with the (single-threaded) patterns we're using today, the application need to be aware of this secret limit and burst away 50 requests at time and then go on to the next 50. Of course we understand that there's some physical limits, but to us; the limit of 50 just seems like a obstinate obstacle
The reason why we prematurely need to check/handle this, is because Tuxedo prohibits you to perform further calls (with reply) if the transaction is in rollback-only-mode (which happens when tpacall returns -1)
Ok, another solution would be to multi-thread us, but that's a bigger challenge for us (now)
Thanx for giving this attention. We will consider a change-request (at least to be able to get the current limit)
If your process is a Tuxedo client, it can be multi-contexted without being multi-threaded. If the process is a Tuxedo server, Tuxedo will transparently multi-thread the server for you, although obviously your code would need to be thread safe. I'm not sure if that helps.
Oracle Tuxedo Chief Architect
when you're mentioning "Tuxedo will transparently multi-thread the server for you", do you refer to "Server-Dispatched Threads" ? If so, I guess that will not solve our immediate design-problem, 'cause:
- all our code is likely not thread-safe
- we're promising Tuxedo to not use threads (by setting TMNOTHREADS=YES)
- multiple server-dispath-threads is semanticly almost equal to having multiple instances/processes adverticed for the same service (right?)
Our objective is that a single-threaded-server (service) needs to retrieve information to a given amount of entities, that (today) only can be made by doin' the same number of service-calls. We wish, without using application-created threads, to be able to call this service concurrently by using tpacall instead of in a sequence ('cause of performance) (and yes, we know that the bottleneck might be the number of instances/threads in the server providing the service). The number of entities (i.e. tpacalls) will in most cases be below 50, but in every place you wanna do this, you have to have some logic where you preventively handle at most 50 a time (and so on) or else you might get a -1 from tpacall and the transaction is set to rollback-only mode and (in Tuxedo) you can't do any further calls (with reply). Ok, in some cases you might be able to tpacall with TPNOTRAN but that is not always applicable
Ok, there are a few design/implementation-patterns that can be made solving the prime issue, but the several-tpacall-solution seemed to be the easiest one except for that limit-of-50-obsticle. And yes, we know that doing more than 50 concurrent calls might get lower performance then calling them in a sequence, but if 98% of all the transactions handles less than, let say, 10, then it we figure it would give an overall performance boost
We will file an enhancement request
Better than best regards,
Försäkringskassan IT Junior Developer