Vaadin Flow server push enablement and transport mode decision

Vaadin Flow keeps UI component state server-side per user session and serializes access with a session lock, so concurrent requests from the same browser are queued rather than processed in parallel. Server push is opt-in per UI and the transport mode is configurable, with documented fallback to long polling when WebSocket is unavailable. Behavior depends on deployment environment and servlet container.

DataProvider lazy loading for components such as Grid triggers backend queries on demand during scrolling, filtering and sorting, with fetch size and caching controlled by application code not by Vaadin internals. Connection pool exhaustion is outside Vaadin scope; Vaadin does not create or close JDBC connections.

An unresolved configuration decision is when to enable server push and which mode to choose, as push increases server resources and connection lifetime while improving UI responsiveness. The trade-off is application specific and version sensitive.

Which UI interaction patterns justify enabling push versus standard request-response? How does push mode selection interact with session locking and servlet container limits? What configuration points determine fallback from WebSocket to long polling in modern Vaadin Flow?