Symfony subrequests and Sulu PHPCR session scope across ESI fragments

Direct answer

Do not give Symfony render/forward subrequests their own PHPCR session by default. They normally share the parent request-scoped PHPCR session and DocumentManager. Real ESI fragments are separate HTTP requests, so each fragment request opens its own session. Reusing one session across subrequests is safe for reads but unsafe for writes unless you control flush ordering, because subrequests share one UnitOfWork, one identity map, and one flush point.

Likely explanation versus confirmed facts

Likely explanation

• Sulu binds the PHPCR session to the Symfony request lifecycle, so nested controllers invoked by render or forward see the same session object.
• ESI esi:include triggers a new sub-request through the HttpKernel, which bootstraps its own container services and therefore its own PHPCR session.
• PHPCR-ODM rolls back uncommitted changes when the request or session ends, so an unflushed write in any fragment is discarded at response completion.

Confirmed facts

• Within one shared session, concurrent edits to the same node are not detected between fragments. The repository reports conflicts at save or flush, for example Jackalope stale-item or workspace-conflict exceptions, not Symfony.
• If one fragment flushes and a later fragment fails, earlier changes can persist while later changes roll back; fragment writes in one parent request are not atomic.
• Sulu 1.x and 2.x differ in bundle registration, Symfony version, and session-factory tagging, but not in the subrequest-shares-session versus ESI-separate-request distinction.
• Jackalope-Jackrabbit and Jackalope-Doctrine-DBAL differ in locking and conflict reporting, but neither backend makes a shared session safe for concurrent fragment writes.

Steps for this case

1. Confirm whether your fragments are Symfony render/forward subrequests or ESI include sub-requests. This is the diagnostic that changes the recommendation.
2. For subrequests, reuse the parent session for reads. For writes, flush explicitly and in the order you want changes applied, or isolate the write in a dedicated service with its own UnitOfWork if you need rollback independence.
3. For ESI fragments, treat each fragment URL as an independent request: it opens, uses, and closes its own PHPCR session.
4. When two fragments write the same node, flush the first, then reload the node in the second before modifying it, and catch repository conflict exceptions at flush time.
5. Check installed Sulu, Symfony, and Jackalope versions and the PHPCR session service scope before changing listeners or service tags.

Verification

Compare spl_object_id() of the PHPCR Session or DocumentManager in the parent controller and inside a subrequest. Identical identifiers indicate a shared request-scoped session. For ESI, call the fragment URL directly and confirm it initializes a separate session.

Assumptions and uncertainty

This answer assumes Sulu’s PHPCR session is request-scoped in your installed version; that is version-sensitive and should be confirmed in the running application. Jackalope conflict exception names are illustrative backend behavior, not guaranteed error codes for your deployment. Treat the Sulu 1.x versus 2.x service-ID differences as unverified until you inspect the container.

Missing diagnostic detail: Are your fragments Symfony subrequests or ESI sub-requests? The answer determines whether you share one session or provision one per fragment.