Package com.enhancedechest.service

Class DbExecutor

java.lang.Object
com.enhancedechest.service.DbExecutor
public final class DbExecutor extends Object
Shared daemon thread-pool for all asynchronous storage work (EnhancedEchest-db).

Owns the single executor every collaborator dispatches DB reads/writes onto, replacing the scattered CompletableFuture.supplyAsync(..., asyncExecutor) pattern with supply(java.util.function.Supplier<T>) / run(java.lang.Runnable). The pool is closed once, last, on plugin disable (after sessions have flushed their pending saves) — see shutdown().

Bounded at the caller-chosen maxThreads, growing from 0 on demand and idling out after 60s of inactivity — the same shape as a cached pool up to that cap, but never beyond it. A handful of paths dispatch one task per online player at once (join preload, the onEnable hot-load loop, /ee reload's permission re-sync), so an unbounded newCachedThreadPool would spawn one OS thread per online player on a large server's restart/reload, each briefly queued behind the DB connection pool — real memory pressure (~1MB stack apiece) for no throughput benefit once concurrency exceeds what the DB side can actually use. Beyond the cap, work queues (unboundedly) rather than spawning further threads or rejecting — every DB call must still eventually run, just serialized behind the cap under a burst.

The cap is sized by the plugin to the storage backend, since threads beyond the JDBC pool's connection count only ever block inside Hikari: a small handful for SQLite's single connection, about twice database.pool-size for MySQL/PostgreSQL (some headroom for tasks doing non-JDBC work — encode, decode, future plumbing — around their DB call).

Implementation note: corePoolSize is set equal to maximumPoolSize with ThreadPoolExecutor.allowCoreThreadTimeOut enabled, not core=0 with an unbounded queue — ThreadPoolExecutor only grows past corePoolSize when the queue rejects an offer, so with an unbounded queue and core=0 it would never spawn a single worker thread and every task would sit in the queue forever. Core-equals-max plus the timeout is the standard idiom for "grows on demand up to a cap, idles out when quiet."

  • Constructor Details

    • DbExecutor

      public DbExecutor(int maxThreads)
      Parameters:
      maxThreads - ceiling for concurrent DB-executor threads; see the class doc for how the plugin sizes this per storage backend

  • Method Details