Imagine the system is experiencing problems. For example; it may be under extremely heavy load, experiencing networking problems, recovering from a hardware failure, etc. etc. As a result "transactions" are taking around 6 seconds.
I was told 90% of my transactions should be completed under 5 seconds. The scenario you said is high-realistic and should be taken into account, but that doesn't mean my system should stop processing longer transactions, it's just a question of creating a smarter algorithm for that.
No. You can still use CMT and set transaction timeout. You just do it through the app server.
If we keep my approach, we need to change the transaction timeout dynamically. I don't think we are able to do that through the app server.
Most app servers already have profiling functionality built in. If your system is experiencing problems it's up to the System Administrator to deal with it - that's their job. Besides, if a system is experiencing extremely heavy load, the app server or infrastructure in general may well implement some kind request throttling. That is, refuse some connections in an attempt to prevent the system from failing completely.
I agree with you, but I'm trying to address the requirements in a deterministic manner. Following your suggestion I will improve the performance for sure, but how do I garantee 90% of transactions under 5 secs?
Maybe I didn't get the point of all these non-functional requirements(NFR). Maybe they are just a guideline for performance tests after deploying the system. After all, how would we "architecturally" garantee 200 concorrent users (another NFR example)? But it's hard to believe that...