# Understand browser request identity and state

Coordinator DB HTTP SQL requests each have a separate logical session. A later browser request does not inherit an earlier request's transaction or temporary tables. Roles and `SET ROLE` are unavailable, so there is no role selection to persist between browser tabs or requests.

Determine the identity from authentication, not from a previous SQL command. An HTTP request uses its configured Basic credentials or Bearer key. If Authorization is absent, the server attempts an explicitly configured empty-password default account. Invalid explicit credentials never fall back to it.

To check recorded identities for recent requests:

```sql
SELECT query_id, user, interface, query_kind
FROM system.query_log
WHERE type = 'QueryFinish'
ORDER BY event_time DESC
LIMIT 10;
```

Use the response query ID to identify the exact browser request; a recent row could belong to another caller. For transaction work, place `BEGIN`, every related statement and `COMMIT` in the same HTTP request. An unclosed transaction rolls back before its response is sent.

Choose a stateful native connection when a task requires a transaction spanning several interactive submissions.

See [HTTP request state](https://coordinatordb.com/docs/concepts/features/interfaces/http), [native sessions](https://coordinatordb.com/docs/concepts/features/interfaces/client) and [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions).