29.01.2014 21:30, Leyne, Sean wrote:
OK, but some of the config options are not compatible for all installed modes
-- so, how do we prevent a user make the wrong selections?
If someone like Paul Reeves (who has been using FB since before it was FB)
doesn't understand all of the
On Thursday 30 January 2014 09:56:50 Dmitry Yemanov wrote:
We introduce a separate (very thin) fblistener.exe (fbremote or
whatever) binary that acts similar to xinetd on posix.
Or maybe we have finally found a reason to keep the guardian ? (At least on
windows.)
Paul
--
Paul Reeves
On 01/30/14 12:56, Dmitry Yemanov wrote:
29.01.2014 21:30, Leyne, Sean wrote:
OK, but some of the config options are not compatible for all installed
modes -- so, how do we prevent a user make the wrong selections?
If someone like Paul Reeves (who has been using FB since before it was FB)
Just a wild idea.
We introduce a separate (very thin) fblistener.exe (fbremote or
whatever) binary that acts similar to xinetd on posix. It will spawn
firebird.exe per every user connection. firebird.exe will detect this
situation and explicitly pass SharedCache = false and SharedDatabase =
On Thursday 30 January 2014 10:43:49 Vlad Khorsun wrote:
Generally speaking, i don't like to introduce new listener. Instead, i
would think - if it is possible to make single common listener
(firebird.exe\.so) to read (per-database) configuration and derive
process\threaded mode from
Technically it is possible to make single instance of firebird.exe to
handle
some attachment requests by forking new CS process and another
attachment requests handling by itself (SS\SC). The question - if it is
possible
to let him know desired mode for given database...
This would
30.01.2014 13:43, Vlad Khorsun wrote:
Technically it is possible to make single instance of firebird.exe to handle
some attachment requests by forking new CS process and another attachment
requests handling by itself (SS\SC).
Do you mean forking the worker after op_connect / op_attach are
I was playing with the different access configurations for FB 3 in
firebird.conf. (with Alpha2)
With this configuration:
SharedCache = true
SharedDatabase = true
and server installed as SS. (ie, instsvc i )
Access via localhost is denied:
C:\Program Files\Firebird\Firebird_3_0isql -user
The reason I was trying this was to try and answer Pavel's question - how do
you run SuperClassic under FB3 on Windows? AFAICT it is not possible.
Really ? :)
I don't mind - SuperClassic seems to share the worst features of SuperServer
and
ClassicServer, and we should officially
On Wednesday 29 January 2014 15:03:02 Vlad Khorsun wrote:
But the questions will be asked - how can we run SC under FB3?
Isn't it was explained when shared page cache was committed ?
Possibly - but I don't think it has been fully documented since then. I'm just
an ordinary clueless user
29.01.2014 18:37, Paul Reeves wrote:
I guess what we really need is to document in firebird.conf how the -m switch
affects the other two settings. There would seem to be a total of eight
combinations.
Lack of -m switch along with SharedDatabase = false means that only the
first connection
On Wednesday 29 January 2014 17:20:16 Dmitry Yemanov wrote:
29.01.2014 18:37, Paul Reeves wrote:
I guess what we really need is to document in firebird.conf how the -m
switch affects the other two settings. There would seem to be a total of
eight combinations.
Lack of -m switch along with
29.01.2014 20:51, Paul Reeves wrote:
# SharedCache SharedDatabase -m Mode
# false false *
SC single attach only
Interesting. Does that differ internally from
# truefalse - ?
SS single attach only
Mostly it doesn't, except the fact that
29.01.2014 18:02, Dmitry Yemanov wrote:
29.01.2014 20:51, Paul Reeves wrote:
# SharedCache SharedDatabase -m Mode
# false false *
SC single attach only
Interesting. Does that differ internally from
# truefalse - ?
SS single attach only
29.01.2014 21:07, Dimitry Sibiryakov wrote:
How about difference latch only vs latch+lock? Does it still exist in v3?
Page locks are not used until the second connection appears. And other
lock types don't affect single-threaded performance.
Dmitry
My last post got munged:
It should have read:
The reality is that there are only 2 set of options::
EngineMode/EngineType = Classic | SuperServer | SuperClassic
DatabaseAccess = Shared | Single
The install options should take their cue from the config settings, and not
require inline
29.01.2014 21:10, Leyne, Sean wrote:
EngineMode/EngineType = Classic | SuperServer | SuperClassic
DatabaseAccess = Shared | Single
The install options should take their cue from the config settings, and not
require inline switches.
Config options are database wise, so using them at the
On Wednesday 29 January 2014 17:20:16 Dmitry Yemanov wrote:
29.01.2014 18:37, Paul Reeves wrote:
I guess what we really need is to document in firebird.conf how the
-m switch affects the other two settings. There would seem to be a
total of eight combinations.
Lack of -m switch
29.01.2014 21:10, Leyne, Sean wrote:
EngineMode/EngineType = Classic | SuperServer | SuperClassic
DatabaseAccess = Shared | Single
The install options should take their cue from the config settings, and not
require inline switches.
Config options are database wise, so using
29.01.2014 18:30, Leyne, Sean wrote:
how will a less experienced user/developer?
They will never change the settings from default which is optimal for most
configurations.
--
WBR, SD.
--
WatchGuard Dimension
On 01/29/14 21:35, Dimitry Sibiryakov wrote:
29.01.2014 18:30, Leyne, Sean wrote:
how will a less experienced user/developer?
They will never change the settings from default which is optimal for
most configurations.
In posix we have shell script making it possible to easily switch
21 matches
Mail list logo
