Bagaimana cara mengoordinasikan pekerjaan bersama lintas tab dengan Web Locks API?

1. Pertanyaan

Beberapa tab dari origin yang sama dapat memperbarui cache IndexedDB dan melakukan sinkronisasi dengan server secara bersamaan. Rancang koordinator yang memungkinkan paling banyak satu konteks melakukan sinkronisasi sementara konteks lainnya menunggu, melewati, atau memeriksa ulang setelah dilepaskan. Bahas penutupan tab, kesalahan jaringan, dan browser tanpa Web Locks.

2. Batasan dan klarifikasi

• Nama kunci dibagikan di seluruh jendela dan worker dari origin yang sama.
• Kunci hanya melindungi cakupan koordinasi callback asinkron; ini bukan transaksi database atau kontrol konkurensi sisi server.
• Sinkronisasi dapat memakan waktu, sehingga memerlukan pembatalan, percobaan ulang (retries), dan siaran versi atau hasil.
• Bedakan antara menunggu kunci, melakukan probing secara langsung, dan membatalkan permintaan.

3. Pendekatan utama

Panggil navigator.locks.request(name, options, callback) untuk meminta named lock. Kunci dilepaskan setelah Promise callback selesai (settles), sehingga callback harus memuat alur baca, sinkronisasi, dan tulis status yang lengkap. Permintaan default akan mengantre; ifAvailable: true memanggil balik dengan null saat sedang sibuk; signal dapat membatalkan permintaan yang masih menunggu.

Manajer kunci melepaskan kunci saat konteks pemiliknya berhenti, tetapi kebenaran data tidak boleh hanya bergantung pada pembersihan saat tab crash. Catatan sinkronisasi harus menyertakan versi, lease, atau kunci idempoten, dan server harus tetap memvalidasi penulisan. Tab lain dapat mengetahui versi baru melalui BroadcastChannel atau dengan membaca ulang IndexedDB.

4. Implementasi referensi

const LOCK = "shared-cache-sync";

async function runSync(signal) {
  return navigator.locks.request(LOCK, { signal }, async (lock) => {
    if (!lock) return { status: "busy" };
    const current = await readSyncVersion();
    if (await isFresh(current)) return { status: "fresh" };
    const result = await fetchAndWriteCache({ signal, baseVersion: current });
    await publishVersion(result.version);
    return { status: "updated", version: result.version };
  });
}

async function trySyncWithoutWaiting() {
  return navigator.locks.request(
    LOCK,
    { ifAvailable: true },
    (lock) => lock ? runOneSync() : { status: "busy" },
  );
}

5. Kebenaran dan penanganan kegagalan

Kunci menyediakan mutual exclusion di antara konteks-konteks dengan origin yang sama untuk sumber daya yang dinamai; kunci tidak melakukan rollback pada permintaan jaringan atau penulisan database. Baca ulang versi sebelum pembaruan bersyarat. Jika jaringan gagal, lempar error (throw) agar kunci dilepaskan dan permintaan berikutnya dapat mencoba lagi. Jangan menyimpan boolean "kita memiliki kunci" di luar callback.

Ketika AbortSignal membatalkan permintaan yang sedang menunggu, pemanggil harus membedakan pembatalan dari kegagalan bisnis. Untuk waktu tunggu yang lama, tampilkan bahwa tab lain sedang melakukan sinkronisasi atau lewati pekerjaan tersebut; setelah pelepasan, baca ulang versi untuk menghindari pembaruan ganda. Pemberitahuan melalui BroadcastChannel merupakan sebuah optimasi; IndexedDB atau server tetap menjadi sumber otoritatif.

6. Tindak lanjut dan jebakan

• Web Locks hanya mengoordinasikan konteks dari origin yang sama; API ini tidak dapat mengunci situs lain, proses server, atau baris database.
• ifAvailable tidak mengantre. Permintaan yang sibuk menerima null, yang merupakan hasil normal.
• steal: true merusak semantik antrean yang ada dan harus dibatasi hanya untuk pekerjaan yang secara eksplisit dapat dibuang dengan pemeriksaan versi.
• Tanpa API ini, BroadcastChannel ditambah IndexedDB dapat memberikan koordinasi best-effort, bukan jaminan mutual-exclusion yang sama; server tetap membutuhkan deduplikasi.

7. Bacaan lanjutan

Bandingkan Web Locks, transaksi IndexedDB, pesan Service Worker, dan BroadcastChannel: kunci menyediakan eksklusi lintas konteks, transaksi menyediakan atomisitas database tunggal, dan saluran menyediakan notifikasi. Eksklusi lintas perangkat atau lintas pengguna menjadi tanggung jawab lease server, API idempoten, atau batasan database.

8. Poin penilaian wawancara

Mampu menyatakan cakupan kunci

Kandidat harus menyatakan bahwa named lock mengoordinasikan jendela dan worker dari origin yang sama, dilepaskan saat Promise callback selesai, dan tidak dapat menggantikan kontrol konkurensi server atau database.

Mampu membedakan mode permintaan

Mereka harus menjelaskan antrean default, probing ifAvailable langsung, dan membatalkan penungguan dengan AbortSignal.

Mampu menangani crash dan duplikasi

Mereka harus menggunakan versi, kunci idempoten, dan penulisan bersyarat, serta menjelaskan bahwa pembersihan tab crash tidak melakukan rollback pada penulisan bisnis.

Mampu memberikan fallback yang jujur

Mereka harus menyediakan jalur best-effort BroadcastChannel/IndexedDB dan menyatakan bahwa mutual exclusion lebih lemah sementara perlindungan server tetap wajib.