if using same session object in same endpoint and not doing retries —
we may need to use session again after an error is being raised , if we don’t rollback the earlier raised error ( in case we are not re-raising it after catch) then session will be in bad state so it won’t be usable so necessarily do session rollback .
what about if error happens while rolling back like db connection loss for extremely small time so if db connection comes back what happens now , what about session object , like connection got interrupted earlier so will using anything related to session cause bad state but the request in server will not drop just because db connection dropped once but it won’t be able to use same session object even if connection comes back even if connection was lost in a happy code path?
doing retries —
is same session object and if error happens in rollback let’s say connection lost with db for some extremely small time and then comes back, so because connection drop is a transient error, we will retry transient errors for idempotent sub functions few times.
use rollback in except block —> db connection drops while rollback —> so now when doing next retry using the same connection will cause bad sesssion state .
if we have not added retries then losing connection with db even once , will it raise error of connection error and drop the request ? because i guess connection needs to constantly stay active .
if server itself goes down then obviously request will be dropped there only .
when calling external api if connection to that is lost request will stay active .
what about if db connection is lost will the request stay active or drop there only ? like we pass a session object via dependency at endpoint start so is it that db connection from db pool will be taken on first db query and not when we are passing a session object at endpoint start ? so if the connection is lost once with db so will the request drop there or it will stay active ? i guess it will stay active so using same session object may cause bad state then?
connection drop plain usage mean db connection drop .
SQLAlchemy/driver only raises DB connection errors when you actually perform DB operations (execute/commit/rollback or explicit connection check). If you’re mid-CPU work and not touching the DB, you won’t get a connection error until the next DB call. If you are in the middle of a DB call (execute/commit/rollback) and the connection dies, that DB call will raise an exception immediately.