DBIO-Forked

 view release on metacpan or  search on metacpan

docs/adr/0002-child-reuses-inherited-sync-storage.md  view on Meta::CPAN

## Decision

The child calls the **ordinary sync CRUD of the inherited primary sync storage**
— `$self->{schema}->storage->$op(@args)`. It re-implements no SQL, touches no
DBI handle, sets no `InactiveDestroy`, and replays no `connect_info`.

- The inherited `_verify_pid` fork handling does the `InactiveDestroy` + fresh
  reconnect in the child by itself.
- That reconnect runs through the sync storage's normal connect path, so a
  configured **AccessBroker** is honoured too — each child reconnects with fresh
  credentials, for free.
- **Anti-recursion**: the child calls the *sync* method (`select`), never
  `select_async` — sync does not route to the async backend (ADR 0028), so there
  is no re-fork.

## Consequences

- Forked is extremely thin: `fork` → inherited sync CRUD → `Storable::freeze` →
  `_exit`. All the heavy lifting (SQL, reconnect, fork-safety, broker) is the
  real driver's, done once in the child.
- The `connect_info` the core resolver hands Forked is **dead weight in Model A**



( run in 0.898 second using v1.01-cache-2.11-cpan-007c89162af )