state-reset appserver and database

[kenny.willems]

Hello,

hopefully someone can help me with this issue.

in our company, all our appservers are stateless appservers. these appservers have databases with a fixed name, so the database are connected from the moment we connect to the appserver.

We also have databases with fixed names, like year and month in the database name. These database should be connected with a state-reset appserver. Now, when i connect my database with the appserver, everything works...for one second.

how can I link my database to the appserver, which is state-reset, without losing my connection.
or are there other (better) solutions for this?

so what do I want to achieve:
use my r-code programs with a database without a fixed database name...

sorry if I didn't give enough information, it's difficult to explain, so please ask more information if needed.

logging

[11/12/01@16:33:17.437+0100] P-565338 T-000000 2 AS AS Application Server connected with connection id: 192.168.15.175::asVoidBIS::5363::bcc80255880ec62d:-50f699bc:133f4f939fc:-7e1f. (8358)
[11/12/01@16:33:17.458+0100] P-565338 T-000000 2 AS CONN Connected to database eopdb, user number 5. (9543)
[11/12/01@16:33:19.882+0100] P-565338 T-000000 2 AS AS Application Server disconnected. (8360)
[11/12/01@16:33:19.883+0100] P-565338 T-000000 1 AS -- State-reset server disconnecting non-command-line database eopdb. (7982)
[11/12/01@16:33:19.883+0100] P-565338 T-000000 2 AS CONN Disconnecting from database eopdb, user number 5. (9545)

 

[tamhas]

Why do you want state-reset? There is no difficulty in sending a request to a stateless appserver and having the agent make a dynamic connection to the desired database.

 

[GregTomkins]

I dont understand how "use my r-code programs with a database without a fixed database name" maps to "state-aware AppServer". We have been using stateless AppServers since day one and I believe this is almost always the way to go.

Maybe I'm missing the point, but to achieve "use my r-code programs with a database without a fixed database name" I would look at the -ld parameter, which lets you treat a database called "foo.db" as it were named "bar" (where "bar" is the argument to the -ld parameter). Of course, you still have to worry about CRC and so forth.

I would respectfully disagree with Tamhas that "there is no difficulty ... making a dynamic connection to the desired database". DB connections tend to be very slow operations, unsuitable for OLTP-type (eg. very frequent, very short-lived) events. That's why you have the notion of connection pooling (thankfully mostly irrelevant in ProgressLand).

On the other hand, connecting every time would be fine if you are starting about something that only happens a few times per day and/or runs for 10 minutes anyway.

 

[kenny.willems]

I'll try to explain:

We have a couple of appservers which connect to databases. all the appservers are stateless appservers, and the database which is connected to it is one of the appserver parameters.

at the end of each month, a end-of-period database is created and a couple of reports ( = same r-code for programs which run on the stateless appservers) are run on this database.

isn't a state-reset appserver the best solution for this situation?

@tamhas: where can I find information about dynamic connection to databases?

thanks in advance

 

[GregTomkins]

Oh, I get it now. You want state-aware so that the client will connect to the same AppServer, which has already done the task of connecting to the right DB. I don't think that's necessary, though. Given you said "a couple of reports" I am going to take back what I said and agree with Tamhas after all. Why not just have the AppServer dynamically connect to whatever DB you need at the start of each call? I assume these reports are only being run a few times, and, that they take a few seconds/minutes/hours/days anyway. In which case, the overhead of making a DB connection will be immaterial.

To connect dynamically you can just put a CONNECT statement in your P4GL code. You can use '-ld' to make the same R-code usable with both DB's. One little gotcha, because of the way Progress implements CRC's and so forth, the CONNECT has to appear in a .P file that is upstream of the first program that uses it. It would look something like this (this surely has syntax errors, but maybe you get the idea):

/* Assume db-primary is automatically connected and p_use_historical_data is true
when they want to switch to a month end copy. Assume p_month contains the month
number. Assume that the relevant DB has been created and is accessible. */

IF p_use_historical_data
THEN DO:
DISCONNECT db-primary.
CONNECT VALUE ("db-copy-" + STRING(p_month) + " -ld db-primary").
END.

/* References to tables in db-primary or db-copy must be made in .P's downstream of here. */

RUN report.p.

Of course, this needs a bunch of error checking and so forth. Also, you have to take care that the structure of db-primary and db-copy-n are identical, otherwise you will get CRC errors and not be able to share R-code.