On Wed, 27 Sep 2017, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
> Can you ellaborate a bit more on this Michael? Like how and where it isused?
(Not mentioning company names, if it's a problem.) I was thinkingabout using it in
various places, but as I don't know how widely they'retested and used and under
what conditions, I didn't had the balls to offerthis as viable alternative against
competing technology X.
> We definitely need more use case studies...
The only problems I've experienced with FPC's support for PostgreSQL
were related to handling SQL queries (e.g. spurious parameter
substitution) rather than to dataflow. As such they were predictable and
could be worked round.
Zeljan once explained an interesting practical problem he had.
He said the connection per transaction model could be dangerous, specially
in a mobile era where connections are often broken, and thus must wait on
timeout. This means during rush times, a server can run out of a fairly
limited ephemeral port inventory before abandoned connections start to time
out.
That is a postgres problem though, not the FPC components.
1. In a REST setting, if you use FastCGI and connnection pooling,
this should not be a problem.
The webserver normally has a reliable connection with the DB server:)
2. On Postgres specifically, you can use PGBouncer.
It mitigates the number of connections to the server.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
