Here is my response:
The best pictures with what arhitecture to choose from and
where to use them
http://www.sinatica.com/blog/en/index.php/articles/firebird-superserver-classicserver-or-superclassic
Is better to be safe creating an new package is easy for super-classic
I proposed to stay the old way and provide all packages
firebird2.5-super
firebird2.5-superclassic
firebird2.5-classic
If the user wants the new superclassic then he can install it
Vlad reply:
And he is wrong – page cache is not shared on SuperClassic
Roman replied :
Classic has one nice property for hosting providers – when somebody use
a buggy UDF, only his process dies, others remain intact.
Also, I’m pretty sure that it is currently not possible, but should be
possible to do in the future, is that we could make the process to run
with the SID of the logged in user (when the PAM authentication is
implemented).
Adriano replied:
Super-classic and Classic will use the same binaries in Linux. But
startup is different.
At the End we all agreed that it’s easier to create an new package for firebird 2.5 named superclassic
Damyan response and final statement:
Thanks for reminding me each architecture’s advantage:
- – classic: full SMP, isolated connections
- – super: shared cache
- – superclassic: full SMP with low OS resource usage
I wanted to provide just one server package for Debian as
I (mistakenly) thought that superclassic uses shared cache too and
didn’t value the isolated connections that much. You do write bug-free
code, right? 😉
Thanks to your comments, instead of cutting, I’ll add a -superclassic
package so that the user can have the final choice.
« Hide it
