PASOE connections to RDBMS - Forum - OpenEdge RDBMS - Progress Community

PASOE connections to RDBMS

 Forum

PASOE connections to RDBMS

This question is answered

Hi,

I saw presentation of Roy Ellis explaining PASOE self-service users seen from Promon: PASA and PASN.

In my configuration connection from pasoe to db is remote and there are only 2 PASN users. Why there is no main process PASA?

You can see promon view here: https://tufotki.pl/Ii9He

Thanks,

Marek

Verified Answer
  • The doc for this is here although it doesn't really explain the difference.

    documentation.progress.com/.../index.html  

    Since remote database connections are managed at the session level, rather than the agent level, unlike self-service connections, you won't see PASA, which is the "agent" level connection.  You will only see PASN which is the which is the individual session connection.

  • Hi Marek,

    Thanks for remembering my slides! As Matt already said in client-server the PASA thread is not used.

    However, I would like to add that there are 2 camps to running self-service or client-server in production. Some customers in production only run client-server and others will only run self-service.

    1) self-service will be faster, but depending on your application the extra performance may be noticed by the users of the application

    2) but client-server has its advantages too, especially if you think you will need to scale horizontally (across several PASOE, or Classic AppServer/WebSpeed instances) to handle load

    Regards, Roy

All Replies
  • The doc for this is here although it doesn't really explain the difference.

    documentation.progress.com/.../index.html  

    Since remote database connections are managed at the session level, rather than the agent level, unlike self-service connections, you won't see PASA, which is the "agent" level connection.  You will only see PASN which is the which is the individual session connection.

  • Thanks Matt. I guess it is better in production to run self-service connection to db.

    Marek

  • Hi Marek,

    Thanks for remembering my slides! As Matt already said in client-server the PASA thread is not used.

    However, I would like to add that there are 2 camps to running self-service or client-server in production. Some customers in production only run client-server and others will only run self-service.

    1) self-service will be faster, but depending on your application the extra performance may be noticed by the users of the application

    2) but client-server has its advantages too, especially if you think you will need to scale horizontally (across several PASOE, or Classic AppServer/WebSpeed instances) to handle load

    Regards, Roy

  • I have often wondered about self-service vs remote connections with PASOE.  Do you have any references which may say which is "better"?  

    In the past a consultant had told us something different.  He said that remote client/server connections are "better" for reasons related to database scalability and overall stability (no risks related to using kill -9 on client applications that may have "shared memory" with the RDBMS itself).  I assume that this applies the same to PASOE applications as it does to any other type of client application that is connected to an OE database.

    Perhaps by "better" you simply mean "faster".  I would agree that this is certainly true, since client/server connectivity to an OpenEdge database is pretty slow...  it is extremely "chatty" relative to other client/server technologies that I've ever worked with ... and it seems to be *extremely* sensitive to network latency.  Unlike with "self-service" connections, the remote ABL application is not allowed to communicate directly via shared memory, and the result is that ABL client/server connections don't perform very well over the network.  (Even OE's "DataServer for SQL" seems faster over the network, but that is a different discussion.)

    I know that there are a variety of optimizations for OE client/server connections (parameters like Mm and prefetch) but it is still a challenge to make client/server apps behave responsively (this effort often involves a lot of code refactoring so that data is gathered proactively via FOREACH NOLOCK - which seems to be the "go-to" optimization technique).

    If you have any references that say which is better for PASOE (self-service or client/server) then I would love to read more on that topic.

  • I guess you are the one to define what is better, it would surprise me if PSC says one or the other. But of course this entire discussion changes when OpenEgde 12 implements server side query resolution which addresses the chattiness and therefor increases the performance when scaling out, as opposed to scaling up. (Standard disclaimers apply :-) )

  • Many thanks for your reply, Roy. I was a bit embarrassed but your and Matt's answers made it clear.

    Thanks again!

  • > On Apr 10, 2018, at 9:01 AM, dbeavon wrote:

    >

    > I have often wondered about self-service vs remote connections with PASOE. Do you have any references which may say which is "better"?

    Neither is “better”. It boils down to tradeoffs amongst the advantages and disadvantages of each compared to your situation and your needs.

    From a technical standpoint, the differences are these:

    A self-serving 4GL client or old appserver agent or a pasoe multi-session agent combines the 4GL client database interface and logic with the database server side logic. the client side communicates with the server side by means of subroutine calls which are quite efficient since there is no inter-process or inter-machine communication involved. client, server, and database all have to be on the same machine.

    A network 4GL client communicates with a separate database server (running on the machine hosting the database) that accesses the database on behalf of the client. The client and server can be executing on the same machine or separate machines. The two parts communicate by means of messages exchanges over a TCP/IP network connection (other network protocols were supported in the past but no needs those anymore).