Describe the bug
When using DatabaseSessionService for persistent sessions in ADK v1.11.0, database sessions are not being closed / rolled back properly in error scenarios. In particular:

• After calling create_session() (or get_session()), if an exception occurs during state updates or commit, the DB transaction remains open and the connection pool fills up (i.e., sessions / transactions not cleaned up).
• The behaviour appears to differ from InMemorySessionService, which handles lifecycle more cleanly.
• With LiteLLM as the model backend the issue is visible under real-load (multiple sessions/requests) and connections start accumulating / errors like “pending rollback” begin showing.

To Reproduce
Here’s a minimal reproducible example (adjusted for v1.11.0 + LiteLLM):

import asyncio
from google.adk.sessions import DatabaseSessionService
from google.adk.agents import Agent
from google.adk.models.lite_llm import LiteLlm
from google.adk.runners import Runner
from google.adk.events import Event
from google.genai import types

DB_URL = "sqlite:///./test_agent.db"  # or your Postgres URL
APP_NAME = "test_app"
USER_ID = "user1"
SESSION_ID = "session123"

session_service = DatabaseSessionService(db_url=DB_URL)  # v1.11.0

model = LiteLlm(model="gemini-2.5-pro")  # example
agent = Agent(
    name="test_agent",
    model=model,
    instruction="Just echo user input",
    tools=[]
)
runner = Runner(agent=agent, app_name=APP_NAME, session_service=session_service)

async def main():
    session = await session_service.create_session(app_name=APP_NAME, user_id=USER_ID, session_id=SESSION_ID)
    # Intentionally raise error or do something bad:
    # e.g., call runner.run() but simulate a tool error / DB violation
    # Repeat many times to simulate load.

asyncio.run(main())

Steps:

1. Install ADK v1.11.0: pip install google-adk==1.11.0.
2. Use LiteLLM backend (as above).
3. Repeatedly create sessions (or resume) and then simulate an error during commit (for example by inserting invalid state or DB constraint violation).
4. Monitor the database connections or logs (SQLite or Postgres) and observe that connections are left open or DB transactions pending rollback.

Stacktrace / symptoms (example):

sqlalchemy.exc.PendingRollbackError: Can't reconnect until invalid transaction is rolled back

or many “idle in transaction” DB connections after repeated failures.

Expected behaviour

• On successful flow: session is committed, refreshed, connection closed.
• On error/exception (e.g., constraint violation, commit failure): the session should roll back and close cleanly (i.e., roll back transaction, release connection).
• The DatabaseSessionService should behave robustly under repeated load/errors without leaking DB sessions/transactions.

Environment

• OS: [e.g., Ubuntu 22.04 or macOS 14]
• Python version: [e.g., 3.11.9]
• ADK version: 1.11.0
• Model backend: LiteLLM (via ADK)
• Database backend: [SQLite / PostgreSQL whichever you’re using]
• Any relevant DB driver or pooling details.

Additional context

• The issue doesn’t appear documented in the existing GitHub issues I found (though there are other issues around get_session filtering and state handling). ([GitHub][1])
• We observed this behaviour under load where many open transactions lead to DB connection exhaustion.
• A workaround on our side was to manually wrap the session factory call in try/except/finally and explicitly rollback() and close() the session if errors occur — which mitigated the leak.
• Given that ADK’s DatabaseSessionService is intended for production persistence (see docs) ([Google][2]), it would be very beneficial for this lifecycle and error-cleanup to be robust out-of-the-box.