[soci-users] how do you know there is a connection?

Post by isoul zi
Not to find in soci functions something like soci :: session :: is_open
Bad looking? It really is not? And you only need to catch the exceptions?

You can check if session::get_backend() != nullptr

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

Krzysztof Bieleń

2013-03-27 11:19:54 UTC

Post by isoul zi
Not to find in soci functions something like soci :: session :: is_open
Bad looking? It really is not? And you only need to catch the exceptions?

You can check if session::get_backend() != nullptr

Hi,

I think that @isoul means that there isn't function which checks if tcp
connection with database isn't broken.

Use case: long running server which doesn't make many queries to server.
Before next query it checks if the tcp connection still exists:

if (!sql.isConnected())
sql.reconect();

// ... do query

It isn't perfect but provides simple pattern for reconnecting when tcp
connection goes out.

Also maybe there should be possibility to create connection_pool with
parameter auto_reconnect = true; which ensures that sessions taken from
connection_pool are connected or it will throw execption.

--
Krzysztof Bieleń

Mateusz Loskot

2013-03-27 11:35:31 UTC

Post by isoul zi
Not to find in soci functions something like soci :: session :: is_open
Bad looking? It really is not? And you only need to catch the exceptions?

You can check if session::get_backend() != nullptr

connection with database isn't broken.

Yes, I sensed that.
I just suggested related test that is currently possible.

Post by Krzysztof BieleÅ
Use case: long running server which doesn't make many queries to server.
if (!sql.isConnected())
sql.reconect();
// ... do query
It isn't perfect but provides simple pattern for reconnecting when tcp
connection goes out.

Yes, good point.

The trick is that implementing session::is_connected with consistent
semantic across variety of backends is not easy, it may be impossible.
For example, function PQstatus check only state cached by libpq library:

session sql(...)
sql.is_connected() -> CONNECTION_OK
// someone unplugs power cord of the database server
sql.is_connected() -> CONNECTION_OK

There is know way libpq to detect external causes of connection lost
It can detect local causes only.
Unless,something has changed in libpq lately

Post by Krzysztof BieleÅ
Also maybe there should be possibility to create connection_pool with
parameter auto_reconnect = true; which ensures that sessions taken from
connection_pool are connected or it will throw execption.

Ricardo Fabiano de Andrade

2013-03-27 12:10:46 UTC

Hi all,

soci really doesn't have this "is_connected" info available and we can't
rely exclusively on exceptions to know that in a portable way across the
different database backends.
So our approach here was modifying soci at the backend level to try
reconnecting automatically during X seconds, making the execution to throw
a distinct message/code in case it can't do it.
I like our solution because it doesn't change soci's public interface and
AFAIK it also applies to connection_pool once all this logic is effective
during statement execution (which will block a while during reconnection
attempts).
It's working for the postgresql backend here, if any of you got interested
I can provide a patch or a pull request.

Regards,
Ricardo Andrade

Post by isoul zi

Post by isoul zi
Not to find in soci functions something like soci :: session :: is_open
Bad looking? It really is not? And you only need to catch the

exceptions?

Post by Mateusz Loskot
You can check if session::get_backend() != nullptr

connection with database isn't broken.

Yes, I sensed that.
I just suggested related test that is currently possible.

Yes, good point.
The trick is that implementing session::is_connected with consistent
semantic across variety of backends is not easy, it may be impossible.
session sql(...)
sql.is_connected() -> CONNECTION_OK
// someone unplugs power cord of the database server
sql.is_connected() -> CONNECTION_OK
There is know way libpq to detect external causes of connection lost
It can detect local causes only.
Unless,something has changed in libpq lately

Good idea, if you would be willing to submit pull request, please do so.
(If it's not a hassle, branch off of 'develop' please into
feature/yourbranch
i.e. feature/pool_auto_reconnect, trying to make us flowed by gitflow :))
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users

Mateusz Loskot

2013-03-27 12:57:26 UTC

On 27 March 2013 12:10, Ricardo Fabiano de Andrade

Post by Ricardo Fabiano de Andrade
soci really doesn't have this "is_connected" info available and we can't
rely exclusively on exceptions to know that in a portable way across the
different database backends.

Indeed.

Post by Ricardo Fabiano de Andrade
So our approach here was modifying soci at the backend level to try
reconnecting automatically during X seconds, making the execution to throw a
distinct message/code in case it can't do it.
I like our solution because it doesn't change soci's public interface and
AFAIK it also applies to connection_pool once all this logic is effective
during statement execution (which will block a while during reconnection
attempts).

Sounds good, could serve as basis for further discussion and work.

Post by Ricardo Fabiano de Andrade
It's working for the postgresql backend here, if any of you got interested I
can provide a patch or a pull request.

If you have *any* code you are willing to share, please, do so.
My point is, even if a pull request won't be merged immediately
or even at all into SOCI codebase, it may be valuable to other users.
I believe that is a great way to support variety and custom-tailored features.
I think gitflow is also helpful here, for example if you submit pull request
with your solution and after review we decide to not to merge it into
master/develop
then I'm happy to merge it into feature/my-awesome-reconnector branch
and publish it at github.com/SOCI/soci as a sort of 'officially approved'
extension, so it also gets more visibility and may inspire new solutions.
I know it's not ideal, but I believe prototyping and variety is a great thing :)

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

Krzysztof Bieleń

2013-03-27 12:30:38 UTC

Post by Mateusz Loskot
The trick is that implementing session::is_connected with consistent
semantic across variety of backends is not easy, it may be impossible.
For example, function PQstatus check only state cached by libpq
library: session sql(...) sql.is_connected() -> CONNECTION_OK //
someone unplugs power cord of the database server sql.is_connected()
-> CONNECTION_OK There is know way libpq to detect external causes of
connection lost It can detect local causes only. Unless,something has
changed in libpq lately

Yes, I'm aware of this. Teoretically I saw people using query like
"SELECT 1" for purpose of checking connection state. Maybe it will be
sufficient solution for default 'is_connected()' for all backends.

I will try to read more about this and how it should be done.

Yes, I thought about this. But lately I'm out of of time so I decided to
write this here along with this topic.

--
Krzysztof Bieleń

Mateusz Loskot

2013-03-27 12:48:01 UTC

There is even PQping, but I'm not sure if silently sampling server over
network is best approach, I've seen it criticised on pgsql- mailing lists.

Post by Krzysztof BieleÅ
I will try to read more about this and how it should be done.

Thanks, I haven't researched it deeply myself, so I'd like to stand corrected.