🚀 go-pugleaf

Craig Stuntz [TeamB] wrote:
> 	Shared caches are simply not possible with Classic. 

That simply wrong statement. Tell that to PostgreSQL folks. Ever heard 
about shared memory between processes ? It's not done in Firebird yet, 
but it doesn't mean it couldn't be done. Look up some old threads about 
the topic in Firebird-Architect.

 > Saying that there
> are a few cases where you might not want to use one doesn't change this
> fact. 

This shared/no shared cache issue goes down to cache at file system. In 
fact, you always have shared cache at file system nowadays. Operations 
at file system cache can collide with large shared cache use pattern in 
a way that will significantly reduce the overall performance, and on the 
other side small not shared cache can give you performance boost.

 > And let's not pretend that they aren't better in general
> applications; that implication is beneath comment. Whereas with
> SuperServer the IB team could rather easily make the cache
> per-connection instead of per-DB if customers were screaming for it. I
> don't seem to see any QC requests for this, though.

Yes, that's done as an option in Vulcan/Firebird 3.0.

> 	The security issues you don't seem to remember are explained
> (accurately, if a bit indirectly) on your own web site:
> 
> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=art_fb_security

This article is dated way back to 2001. A lot changed in Firebird 
security front since that. You have to have group access with classic in 
local settings (which means true embedded mode), but that requirement is 
natural for any such system. With access over TCP/IP, Classic is as 
secure as Super Server, if not more.

best regards
Pavel Cisar
IBPhoenix