Hi Guys,
Background: Need to convert an existing distributed chui application to the web, but maintaining the same distributed infrastructure of 70+ servers. The current application employs persistent procedures and the conversion requires that we separate out the ui and business logic, keeping as much original code as possible.
Two questions:
1. Can I run persistent procedures in a webpseed application which is stateless?
2. Is there any good reason to use persistent procedures in a stateless environment?
Regards,
Andrew
1. Yes, you can run persistent procedures in a stateless environment (WebSpeed or AppServer).. Doing so has some downsides, like locking the agent for the time the persistent procedure is running, but as long as your calls are short and you make sure you clean up, it can work just fine.
2. No, but that is just my opinion..
2. No, but that is just my opinion..
I'd say that if you start the PPs when the AppServer starts up, then there can be some value in having PPs that persist longer than a call. I agree with Kevin that it's a bad idea to start, call and stop a PP all from the client for just one call.
-- peter
So if there's little reason to use PPs in a Webspeed stateless environment, is there any good reason to use them in the Appserver arena?
Would there be any benefit in running an Appserver with a Webspeed stateless environment either?
Regards,
Andrew
1. Yes, you can run persistent procedures in a stateless environment (WebSpeed or AppServer).. Doing so has some downsides, like locking the agent for the time the persistent procedure is running, but as long as your calls are short and you make sure you clean up, it can work just fine.
You only lock the agent if you call the persistent procedure directly from an Appserver client. This is certainly a bad idea, but it is quite common to have persistent procedures running both on stateless AppServer and Webspeed agents. This can be "class" or manager super procedures that are started as part of the agent startup or on demand. You can also do this for application objects (persistent instances). Our existing frameworks Dynamics and ADM2 always keeps the super procedures running and also supports the ability to keep SDOs running on server both on AppServer and WebSpeed.
2. No, but that is just my opinion..
If you have super procedures that are needed on each request you would likely benefit from only starting them once. It is a bit more questionable and complicated to keep application objects alive. If there are too many you might use too much memory and even loose the perceived benefit.
Message was edited by: Havard Danielsen
Clarified that it is common to have persistent procedures on stateless agents
So if there's little reason to use PPs in a Webspeed stateless environment, is there any good reason to use them in the Appserver arena?
I do not think there is any difference. It depends more on how they are used and how many users you need to serve. The faster you can make each request the more users you can serve in the same amount of time. One of the simplest ways to decrease request time is to keep persistent objects alive. But if you keep too many objects alive you start bogging down memory (on each agent)and many objects may also increase the overhead of refinding the persistent procedure. I have seen implementations that just scanders the benefit from not restarting an object by the mechanism used to keep track of and refind the object.
Bottom line is that you can gain a lot, but it is easy to loose it all.
I have not tested OO in this context yet. I suspect a singleton pattern might improve this for infratructure classes.