On NT the problem is just a constant in the code - this has been proved as I
have tested a build 5.7 that kept on going past 500 connections.

I don't think there are any plans to release this version though.

JAC.

----- Original Message -----
From: Fabricio Araujo <fabricioa@...>
To: Interbase Architecture List <IB-Architect@egroups.com>
Sent: 15/09/2000 5:02 AM
Subject: [IB-Architect] Context connections


>
> Hi,
>
> After MUCH lurkering, I decided to get to talk a little... ;-)
> Well, my idea is a way to address the problems with some
> OSs (Win9x/NT, Linux, Solaris) regarding multiple ( more than
> 255) network connections.
> Those that accompanied this forum since the start (under
> the Wolf realm), knows what I saying. For those newbies:
> some guys detected that Solaris (and after this, NT and
> Linux also) have trouble to mantain more than 255.
> Some guys asked that it is a Interbase problem, but JimS
> got some library code to prove that is a OS problem, not
> the server.
> But I think that us can provide some ways to circunvent
> it and (in the shower ;-) ) I got a way. I named it: context
> connections.
> Before continuing, some abbreviations to easy my text:
> * NC - network connection
> * DC - database connection
>
> Actually, a DC to a Interbase server is made with
> a attached NC
> After that, the server uses whatever methods to verify
> that the (network and DB) conn is alive.
> In my vision, when a client need to make a DC to the server,
> it starts (obviously) a NC and IB start a DC thread (or process,
> in Classic Architecture). But, * when it connects and gets a autorized
> connection *, the client lib gets a ContectID and close the NC.
> And the DC? Nothing change: it's still opened.
> When that connection needs to start a transaction, the client lib
> open a new NC and connects as usual, except that IB does not
> make the authentication or any other info, since that client passes the
context ID
> (maybe the logon/password also, if is needed that so much authen-
> tication; I think that it's not needed all the time).
> The NC will continue open:
> * Until the transaction closes
> * Until a certain number of transaction is reached (configured on start
transaction API - wherever is more adequate, my raw IB API
> knowledge is not that much)
> * Until a certain timeout is reached (the transaction continues processing
on server, but NC is killed)
> * Until the rows fetched reaches the client
> * A combination of above
> * Other ideas? ;-)
>
> I think this can improve the number of connections and save some resources
that can
> be used to speed queries, row/metadata cache, etc...
>
> What you all think of this?
>
> []s Fabricio
>
>
>
>
>
> []s Fabricio
> Delphi C/S Developer
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
>