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=
/tmp/ttt.gdb"

--- In ib-support@y..., "Paul Beach" <pabeach@w...> wrote:
> > you ARE talking about LIBS here, right? If so, it's contrary to what y=
our
> 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=
he
> Delphi disks limited the number of LIBS connections to four. The slownes=
s
> of LIBS as >compared with a localhost or remote connection was demonstrab=
le.
> The flakiness of LIBS when threading is involved (e.g. when *legally* usi=
ng
> unlimited >multiple LIBS threads from a web application) didn't really c=
ome
> to the surface until open source removed the licensing limitations.
>
> The license linited the no. of connections and only allowed local not rem=
ote
> 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=
d
> 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=
me
> inter-process >communication space. IOW, additional threads overwrite =
and
> corrupt one another's messages, or try to and cause GPFs. He commented t=
o
> the effect that >LIBS was designed that way and it wasn't likely to be fi=
xed
> 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=
er
> 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 =
so
> long as you put the relevant (non thread safe code) into critical section=
s.
> 5. The issue re. threading and non thread safe InterBase, seems to now co=
me
> down to a botched implementation of gds32.dll, and the fact that arrays a=
re
> not handled properly. Threading seems to work, unless your database happe=
ns
> to have arrays. Ann has more details on this. Something we need to look a=
t
> 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