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 )