>> => Does that mean: We have a single executable in Firebird 3. When -m is >> used, this means a single server process and the SharedCache, >> SharedDatabase parameters controll whether it's SS or SC. When -m is not >> used, then it's one process per connection thus CS. >> >> Is this correct? > > Basically, yes. > > The question is what to do if the config options conflict with the > running mode. There was a suggestion to adjust the -m setting > dynamically, depending on the SharedDatabase option. It counds suitable > at the first glance. However, I foresee some issues if someones > explicitly installs "SuperServer" but it actually runs as "Classic", or > vice versa :-)
Whenever there are options, things can get confusing. ;-) I possibly overstress that area, so I'm sorry to continue the discussion ... *g* * Under the assumption that SS as a single-process model with it's shared cache supports SMP (I think this was a primarly goal) in 3.0 like SC in 2.5, I don't see a reason to offer SC in 3.0 at all (at least the SC terminology; which already shows up in the missing SC part in "instsvc")? * Or are there any benefits running a non-shared cache single-process model against the shared cache counterpart? A shared cache model IMHO offers a more predictable way for system operations from a page cache (RAM) usage POV * Unlike InterBase customers, I guess Classic won't be abonded, cause current Firebird customers still want the per-connection fail-resistant sandbox behaviour * How does Embedded 3.0 fit in here? SS still with the shared database option? Regards, Thomas ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
