On 5/29/2020 5:23 AM, Radosław Korzeniewski wrote:
Hello Alan,
śr., 27 maj 2020 o 17:02 Alan Brown <a.br...@ucl.ac.uk
<mailto:a.br...@ucl.ac.uk>> napisał(a):
Database connections are _supposed_ to be stateless.
I'm very surprised about the above statement as I cannot imagine such
functionality already available in any SQL database I'm familiar with.
If you drop a connection to the database in the middle of the
transaction then your transaction will rollback. So, no it is not a
stateless connection.
Or I misunderstood your statement.
It is stateful by definition, since information is stored. (The client
is authenticated, etc.) Also, there are distinct states after
connecting; waiting to issue, issue query, wait for answer, then back to
waiting to issue. A query is atomic, from the client's perspective, so
must fail if the connection is dropped prior to the answer. However,
while in the 'waiting to issue' state a re-connect is certainly
possible, so a dropped connection while in the wait state does not have
to be fatal. Checking connection state before each query would result in
painfully slow performance, but it should be done once just before the
catalog updates for a job are made. If a job is acquiring a db
connection at job start, then there may be quite some time between the
start of the job and actually updating the catalog. It would be more
robust for the time between the db connectivity check and the actual
issuing of queries to be made as short as possible, because it lowers
the probability of a dropped connection interrupting the job.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
