Why mod_harbour v3's Persistence Isn't Enough for Production
mod_harbour v3 does have persistent state. The Harbour VM stays alive inside the Apache child process — your statics survive, your publics survive, your variables stay in memory between requests. That's a huge step up from CGI.
But raw persistence and production-grade persistence infrastructure are two very different things. mod_harbour v3 gives you a chunk of memory that stays alive. What you do with it is entirely up to you.
mod_harbour v3: Request → VM runs → statics/publics survive → next Request
↑
raw memory — you build everything yourself
mod_WebX: Request → VM runs → hPersistent → next Request
↑
code cache, DB pool, sessions,
rate limits, cache — organized, thread-safe,
with APIs and lifecycle management
What mod_harbour v3 gives you:
-
Harbour VM embedded in Apache (persistent across requests)
-
Static and public variables survive between requests
-
AP_RPuts(), AP_GetEnv(), AP_HeadersIn() — basic request/response
-
Raw building blocks — the rest is your problem
What mod_WebX builds on top of that persistence:
1. Compiled Code Cache
Your statics persist in v3, sure — but do you have automatic bytecode caching with file fingerprinting? mod_WebX stores compiled .hrb in hPersistent["codecache"], checks the file's date+time+size on each request, and only recompiles when the source actually changes. You get 20-80ms back on every request without writing a single line of cache management code.
2. Database Connection Pool
In v3 you could store a database connection in a static variable. But what about health checks? What if the connection drops? What about multiple named pools for different databases? mod_WebX provides hPersistent["dbpool"] with automatic health validation, named pools, usage stats, and clean teardown on shutdown. Connect once, reuse forever — without writing your own connection manager.
3. In-Memory Cache with TTL
In v3 you could stuff values into a static hash. But when do they expire? How do you track hit rates? mod_WebX provides hPersistent["cache"] with automatic TTL expiration, hit/miss statistics, and a "remember" pattern that only runs the expensive query when the cache is cold. Zero latency, zero serialization — no Redis server needed.
4. In-Memory Sessions
In v3 you could roll your own session system with statics. But you'd need to handle cookie generation, HttpOnly flags, SameSite policy, IP tracking, timeout eviction, and session ID regeneration after login (to prevent fixation attacks). mod_WebX provides all of this in hPersistent["sessions"] out of the box. No disk I/O, no file locking, no external session store.
5. Rate Limiting
This one you'd have to build from scratch in v3. Sliding window counters per IP, per endpoint, with configurable limits and automatic cleanup of old entries. mod_WebX provides hPersistent["ratelimit"] with named limits — 5 logins per 5 minutes, 60 API calls per minute, 10 uploads per hour — all in-process, zero latency.
6. Thread Safety
This is the one that bites you. In v3, if two requests hit the same static variable simultaneously, you have a race condition. mod_WebX wraps all persistent access in an APR mutex. Every read and write to hPersistent goes through a lock. You don't think about threading — it just works.
The Performance Gap:
Requests per second
Response time
-
mod_harbour v3: 20-50ms (recompiling, reconnecting)
-
mod_webx: 2ms (cached code, pooled connections)
Memory usage (100 concurrent users)
Database connections (100 concurrent users)
Code compilation
Sessions
-
mod_harbour v3: Roll your own or use external store
-
mod_webx: Built-in, in-process, with security hardening
Rate limiting
-
mod_harbour v3: Not available (build from scratch)
-
mod_webx: Built-in, sliding window, per-endpoint
TL;DR
TL;DR
mod_harbour v3 gives you a persistent VM. That's the foundation — and it's good.
But between "my statics survive" and "I have a production web server" there's a massive gap: code caching, connection pooling, session management, cache TTL, rate limiting, and thread safety. That's what mod_WebX fills.
mod_harbour v3 = persistent engine
mod_WebX = persistent engine + transmission + fuel system + dashboard + safety systems
You can build all of this yourself on top of v3. But that's months of work, and you'll be solving problems (thread safety, session fixation, connection health checks, cache eviction) that have nothing to do with your actual application.
Standing on the shoulders of giants
None of this would exist without the work of Antonio Linares (mod_harbour) and Manu Expósito (the v3 fork). Both are jewels of engineering — embedding a full Harbour VM inside Apache, with clean request handling and persistent state, is no small feat. They just never got the attention they deserve.
mod_WebX doesn't replace their work. It builds on it. The persistent VM is the foundation that makes everything else possible. We just added the production infrastructure that turns that foundation into something you can deploy without writing your own web framework from scratch.
