nipunsharma12 opened a new issue, #93:
URL: https://github.com/apache/casbin-jcasbin-jdbc-adapter/issues/93

   ## Problem
   
   The current `JDBCBaseAdapter` holds a single `Connection` for the entire 
lifetime of the adapter instance (assigned in the constructor and never 
released until `close()` is called). This causes several issues:
   
   1. **No connection pooling** — Even when a pooled `DataSource` (e.g., 
HikariCP, Apache DBCP) is provided, only one connection is ever borrowed from 
the pool, defeating the purpose of pooling.
   2. **Not thread-safe** — The shared mutable `conn` field is accessed from 
all adapter methods without synchronization, leading to race conditions in 
concurrent environments.
   3. **Stale/broken connections** — If the connection drops (network timeout, 
DB restart), the adapter becomes unusable until `retry()` happens to replace 
it. The retry mechanism itself is fragile since it just overwrites the field.
   4. **Resource leaks** — `setAutoCommit(true)` in `finally` blocks can fail 
on a broken connection, and the single connection ties up a DB slot for the 
full application lifetime.
   
   ## Proposed Solution
   
   Replace the persistent `Connection conn` field with 
**connection-per-operation** semantics using try-with-resources:
   
   - Each public method (`loadPolicy`, `savePolicy`, `addPolicies`, 
`removePolicy`, etc.) obtains a fresh connection from 
`dataSource.getConnection()` and releases it at the end of the operation.
   - Transactional operations (`removePolicies`, `updatePolicy`, `savePolicy`) 
share a single connection within the method scope for atomicity.
   - The `retry()` helper and `conn` field are removed entirely — Failsafe 
retry naturally works by getting a new connection on each attempt.
   - `close()` becomes a no-op (kept for backward API compatibility with 
`@Deprecated`).
   
   ## Benefits
   
   - **Enables connection pooling** — Users can supply a HikariCP/DBCP/Tomcat 
JDBC `DataSource` and connections are properly borrowed and returned.
   - **Thread-safe** — No shared mutable connection state across operations.
   - **No stale connections** — Each operation gets a fresh (or pool-validated) 
connection.
   - **Proper resource cleanup** — try-with-resources guarantees connection 
release even on exceptions.
   - **Backward compatible** — The `DataSource` interface contract is 
unchanged; users who pass `JDBCDataSource` (raw `DriverManager`) still work, 
just without pooling benefits.
   
   ## Files Changed
   
   - `JDBCBaseAdapter.java` — Core refactor (remove `conn` field, add 
try-with-resources to all methods, extract `removePolicyWithConnection` for 
transactional use)
   - `JDBCAdapter.java` — Update `loadFilteredPolicyFile` to use 
connection-per-operation


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to