| Subject | Re: [firebird-php] Re: Simultaneous Connections |
|---|---|
| Author | Helen Borrie |
| Post date | 2013-01-25T22:23Z |
At 10:04 a.m. 26/01/2013, jackdmason wrote:
Classic could always allow multiple instances of itself to open the same database simultaneously. Superclassic, which came with v.2.5, is really just a multi-threaded Classic. Fb embedded was always Classic on POSIX platforms but was previously a modified Superserver on Windows. In 2.5, Fb embedded is Superclassic on all platforms - hence the information you quote is true but you are confusing yourself by interpreting that info as referring to *client connections*.
That text would be less ambiguous if it read "Only Classic and Superclassic allow a regular server and one or more embedded servers to manage connections to the same database simultaneously." Can you tell us the source of your quote, so we can improve it?
No server (any brand!) can accommodate an unlimited number of *client* connections, since each connection uses resources on the server. Eventually, any server will have insufficient resources to make new connections. That is one limitation for client connections. Another may be the some limitation imposed by the host network configuration. Firebird servers don't limit the number of connections.
That said, Superserver was (in the past and still in InterBase, AFAIU) hobbled to 1024 connections, regardless of server resources, for some reason related to the range limits of some variable in the SS engine. It was a design fault that went away in Fb quite early, possibly 1.5 or 2.x. But, in reality, because page sizes and therefore cache buffers are potentially much bigger as the Fb versions ascend, there's a strong likelihood anyway, that server resource limits will be reached when the connection count is quite a lot lower than that old SS limit.
Helen
>It may not be a problem. Here is what the documentation says:This quote refers to *servers*, not clients. The Golden Rule with InterBase and with older versions of Firebird is/was that two **servers** could not be accessing the same database simultaneously. Prior to Fb 2.5, that meant that you could not/cannot simultaneously run both an embedded server application and a Superserver that is serving remote connections.
>
>Simultaneous connections
>
> Only Classic and SuperClassic allow simultaneous connections to a database from the regular server and one or more embedded servers. Thus, if you use the Windows Embedded Server, it may be advantageous to have Classic or SuperClassic as your regular server.
>
>It is not even clear to me what that means exactly. InterBase has allowed our applications to run without a limit on "simultaneous" connections. MySQL allows us apparently an unlimited number. What is Firebird limiting?
Classic could always allow multiple instances of itself to open the same database simultaneously. Superclassic, which came with v.2.5, is really just a multi-threaded Classic. Fb embedded was always Classic on POSIX platforms but was previously a modified Superserver on Windows. In 2.5, Fb embedded is Superclassic on all platforms - hence the information you quote is true but you are confusing yourself by interpreting that info as referring to *client connections*.
That text would be less ambiguous if it read "Only Classic and Superclassic allow a regular server and one or more embedded servers to manage connections to the same database simultaneously." Can you tell us the source of your quote, so we can improve it?
No server (any brand!) can accommodate an unlimited number of *client* connections, since each connection uses resources on the server. Eventually, any server will have insufficient resources to make new connections. That is one limitation for client connections. Another may be the some limitation imposed by the host network configuration. Firebird servers don't limit the number of connections.
That said, Superserver was (in the past and still in InterBase, AFAIU) hobbled to 1024 connections, regardless of server resources, for some reason related to the range limits of some variable in the SS engine. It was a design fault that went away in Fb quite early, possibly 1.5 or 2.x. But, in reality, because page sizes and therefore cache buffers are potentially much bigger as the Fb versions ascend, there's a strong likelihood anyway, that server resource limits will be reached when the connection count is quite a lot lower than that old SS limit.
Helen