Subject Re: Firebird works.
I´m wrong or the conclusion is: "Never user local mode on Interbase" ?
My system is linux/FreeBSD.
Note I do not mean connections using localhost:/.. but something a la "isql=

--- In ib-support@y..., "Paul Beach" <pabeach@w...> wrote:
> > you ARE talking about LIBS here, right? If so, it's contrary to what y=
> user support people would say - and I'm talking here not about 16-bit v.4=

> but 32-bit v.4.x and 5.x.
> Yup.
> > The understanding I had was that the IB licensing that installed from t=
> Delphi disks limited the number of LIBS connections to four. The slownes=
> of LIBS as >compared with a localhost or remote connection was demonstrab=
> The flakiness of LIBS when threading is involved (e.g. when *legally* usi=
> unlimited >multiple LIBS threads from a web application) didn't really c=
> to the surface until open source removed the licensing limitations.
> The license linited the no. of connections and only allowed local not rem=
> connections. The Local Interface (Inter Process Communication) was
> implemented into SuperServer, so that we would see the same kind of
> performance for local connections on windows for SuperServer as we
> originally did for Classic. The IPC mechanism was then meant to be rolle=
> out to other platforms. It didn't happen for a number of reasons.
> > Charlie Caro attributed the LIBS blow-ups with multiple threads to the
> fact that, with local connections, the client and the server share the sa=
> inter-process >communication space. IOW, additional threads overwrite =
> corrupt one another's messages, or try to and cause GPFs. He commented t=
> the effect that >LIBS was designed that way and it wasn't likely to be fi=
> because it wasn't broke. My inference: now I understood why IB support
> would say "LIBS wasn't >intended for deployment".
> 1. If Borland are saying that LIBS isn't for deployment, then the message=

> has changed :-)
> 2. LIBS uses the same IPC mechanism as the full server, no difference, so=

> you could argue that you shouldn't use local connections on the full Serv=
> version as well as LIBS, if you can't deploy LIBS for local access, you
> shouldn't deploy the full server :-)
> 3. The IPC implementation as Charlie correctly identifies, does have its
> flaws.
> 4. The main issue re. threads etc was because the local gds32.dll wasn't
> thread safe, on analysis you can write decent threaded routines for LIBS =
> long as you put the relevant (non thread safe code) into critical section=
> 5. The issue re. threading and non thread safe InterBase, seems to now co=
> down to a botched implementation of gds32.dll, and the fact that arrays a=
> not handled properly. Threading seems to work, unless your database happe=
> to have arrays. Ann has more details on this. Something we need to look a=
> in more detail and fix.
> > >The only difference, tended to be the license key :-)
> >
> > ..when licensing was in effect, yes; once licensing was gone, the REAL=

> differences surfaced and caused problems. Is this not the case?
> The only difference between LIBS and Full Server is the license key. The=

> same local connection problems would exist on LIBS and Full Server.
> Regards
> Paul