# Connect concurrent applications safely

Several applications can connect to one Coordinator DB server using native TCP or HTTP. The server's public connection and request limits determine how admitted work is bounded. This is different from opening the same database file independently in several processes.

Multiple connections within one process can share a file. Simultaneous access to the same file from separate processes is outside the supported concurrency model. If callers live in separate applications, connect them to one server process or give them independent database copies.

Native connections retain transactions and temporary tables. Closing a connection rolls back its uncommitted work. HTTP requests each have their own session, so an explicit transaction must start and finish in one request. Do not spread a transaction across several HTTP calls and assume they share state.

Observe active work before adjusting limits:

```sql
SELECT query_id, user, interface, elapsed
FROM system.processes
ORDER BY elapsed DESC;
```

The snapshot can include the observing request and does not guarantee that a listed request is still present later. Review admission settings and application retry behavior together when requests encounter locking or admission failures.

See [deployment modes](https://coordinatordb.com/docs/get-started/about/deployment-modes), [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions) and [server limits](https://coordinatordb.com/docs/reference/settings/server-settings/settings/max).