Mir ist aufgefallen, dass dieses Verhalten in Java-Umgebungen normalerweise nicht auftritt (Verbindungen werden sofort geschlossen, es sei denn, @Transaction hält sie offen), daher finde ich dieses Verhalten in Python seltsam.
Ich vermutete, dass es damit zusammenhängen könnte Das Verbindungspooling von SQLAlchemy hält Verbindungen für die Wiederverwendung aufrecht. Ich habe versucht, den Verbindungspool zu deaktivieren (mit NullPool), aber die Verbindung bleibt immer noch in der Datenbank „ruhend“.
Hier ist mein Datenbank.py-Setup:
Code: Select all
# Session configuration
SessionLocal = sessionmaker(
autocommit=False,
autoflush=False,
expire_on_commit=False,
bind=Engine
)
def get_db() -> Generator[Session, None, None]:
db = SessionLocal()
try:
yield db
except Exception as e:
print(f"Error in session: {e}")
db.rollback()
raise e
finally:
print("Closing database session.")
db.close()
Code: Select all
# Inside a FastAPI route
integracao_data = IntegracaoPDVCreate(
idEstabelecimento=id_estabelecimento_fixo,
tipo=tipo_arquivo,
dadosArquivo=texto
)
# CRUD operation
db_item = crud.create_integracao_pdv(db=db, item=integracao_data)
# Critical Commit
db.commit()
# Refresh the item (starts a new implicit transaction/select?)
db.refresh(db_item)
- Ist es normal, dass SQLAlchemy mit pyodbc Verbindungen in einem „schlafenden“ Zustand belässt, auch nachdem db.close() im „finally-Block aufgerufen wird?
- Hält db.refresh(db_item) die Verbindung nach dem geöffnet? commit?
- Wie kann ich sicherstellen, dass die Verbindung physisch geschlossen oder korrekt an den Pool zurückgegeben wird, ohne Artefakte in SQL Server zu hinterlassen?
- Python 3.x
- FastAPI
- SQLAlchemy
- SQL Server
- Treiber: ODBC-Treiber 17 für SQL Server
Mobile version