native sql statement to setup table

[jesperlarsson1910]

Summary by CodeRabbit

• Refactor
  • Enhanced logging infrastructure with optimized initialization mechanism for improved thread-safety and performance.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Introduced lazy initialization of a logging table in the LoggingConnection class using double-checked locking. A new private static method setupLoggingTable() creates an app_logs table on first connection acquisition, with synchronization to ensure thread-safe initialization.

Changes

Cohort / File(s)	Summary
Logging Table Initialization src/main/java/org/example/logging/LoggingConnection.java	Added java.sql.Statement import; introduced volatile started flag and lock object for double-checked locking; implemented setupLoggingTable() method to create app_logs table on first use; modified getConnection() to trigger lazy initialization before returning DataSource connection

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A table blooms when first we call,
With locks held tight, we heed the sprawl,
Double-check the eager hare,
Lazy init beyond compare!
Logging flows where once was spare. 📝✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a native SQL statement (CREATE TABLE IF NOT EXISTS) to set up the app_logs table during lazy initialization.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7944751 and e104476.

📒 Files selected for processing (1)

• src/main/java/org/example/logging/LoggingConnection.java

🚧 Files skipped from review as they are similar to previous changes (1)

• src/main/java/org/example/logging/LoggingConnection.java

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 4

🤖 Fix all issues with AI agents

In `@src/main/java/org/example/App.java`:
- Line 4: Remove the unused import LoggingConnection from App.java: locate the
import statement "import org.example.logging.LoggingConnection;" at the top of
the file and delete it (or comment it out) since there is no reference to the
LoggingConnection type in class App; if the import was meant for upcoming work,
instead add a brief TODO comment near the class explaining the future use and
keep the import out until it is actually used.

In `@src/main/java/org/example/logging/LoggingConnection.java`:
- Around line 15-16: The non-volatile static boolean started in
LoggingConnection causes a race when multiple threads call getConnection() and
may concurrently call setupLoggingTable(); fix by making started thread-safe
(e.g., change started to a private static volatile boolean or replace with a
private static AtomicBoolean) and apply double-checked locking: in
getConnection() first check started, if false enter a
synchronized(LoggingConnection.class) block, check started again, call
setupLoggingTable() and set started = true (or atomic.set(true)); ensure the
synchronized block wraps only the initialization so other connection logic
remains concurrent and that exceptions during setup do not leave started set to
true.
- Around line 39-47: The code in LoggingConnection currently calls
ds.getConnection() and createStatement() without closing them; replace the try
block with a try-with-resources that acquires a Connection (from
ds.getConnection()) and a Statement (from conn.createStatement()) so both are
auto-closed after executeUpdate(createTableSQL), then set started = true inside
the try; keep the existing SQLException handling (rethrow as RuntimeException)
but remove manual resource management. Use the LoggingConnection class and the
local variables conn and stmt to locate the change.

In `@src/main/java/org/example/MyPod.java`:
- Line 35: Remove the unused import of LoggingConnection from MyPod.java: delete
the line importing org.example.logging.LoggingConnection since the class MyPod
does not reference LoggingConnection (ensure no other references to
LoggingConnection exist in class MyPod before removal).

🧹 Nitpick comments (1)

src/main/java/org/example/logging/LoggingConnection.java (1)

29-50: Consider making setupLoggingTable() private.

Since getConnection() now handles lazy initialization internally, exposing setupLoggingTable() as public creates two entry points for the same behavior. If callers invoke it directly while others use getConnection(), the initialization logic becomes harder to reason about.

♻️ Suggested change

-    public static void setupLoggingTable() {
+    private static void setupLoggingTable() {

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 54695ca and 7944751.

📒 Files selected for processing (3)

• src/main/java/org/example/App.java
• src/main/java/org/example/MyPod.java
• src/main/java/org/example/logging/LoggingConnection.java

🧰 Additional context used

🧬 Code graph analysis (2)

src/main/java/org/example/MyPod.java (1)

src/main/java/org/example/logging/LoggingConnection.java (1)

• LoggingConnection (10-58)

src/main/java/org/example/App.java (1)

src/main/java/org/example/logging/LoggingConnection.java (1)

• LoggingConnection (10-58)

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Race condition on started flag in concurrent access.

The started field is a non-volatile boolean accessed without synchronization. When multiple threads call getConnection() concurrently before initialization completes, each may see started == false and invoke setupLoggingTable() simultaneously. While the SQL is idempotent, this wastes resources and compounds the connection leak issue.

Consider using a thread-safe initialization pattern:

🔒 Proposed fix using double-checked locking

-    private static boolean started = false;
+    private static volatile boolean started = false;
+    private static final Object lock = new Object();

     public static Connection getConnection() throws SQLException {
-        if(!started){
-            setupLoggingTable();
+        if (!started) {
+            synchronized (lock) {
+                if (!started) {
+                    setupLoggingTable();
+                }
+            }
         }
         return ds.getConnection();
     }

Also applies to: 52-56

🤖 Prompt for AI Agents

In `@src/main/java/org/example/logging/LoggingConnection.java` around lines 15 -
16, The non-volatile static boolean started in LoggingConnection causes a race
when multiple threads call getConnection() and may concurrently call
setupLoggingTable(); fix by making started thread-safe (e.g., change started to
a private static volatile boolean or replace with a private static
AtomicBoolean) and apply double-checked locking: in getConnection() first check
started, if false enter a synchronized(LoggingConnection.class) block, check
started again, call setupLoggingTable() and set started = true (or
atomic.set(true)); ensure the synchronized block wraps only the initialization
so other connection logic remains concurrent and that exceptions during setup do
not leave started set to true.