Subject | Re: Connection Strings |
---|---|
Author | nitaligavino |
Post date | 2002-10-15T15:04:09Z |
Hello:
From my understanding, and experience using the API directly via c /
c++, using local verses TCP/IP connection sets up the DB internals
differently. When a connection is made using a local path, e.g.,
c:\database\test.gdb, the gds32.dll in turn runs under a single
threaded model, not the super-server model. Therefore if you attempt
to establish another connection to the database the second attempt
will deadlock. Your application will stop responding. Likewise if
you attempt to share this single connection among threads you will
also deadlock your application. However, when connection via the
TCP/IP connection, e.g., localhost:c:\database\test.gdb, the server
internally runs as a super-server and supports multithreaded
clients. You can then create a connection for each application
thread without the deadlock issue.
Please be aware I'm not claming any great knowledge of the DB
internals, I'm only sharing my experience and information that I
uncovered while asking the same question, correct or not!
Dan
--- In ib-support@y..., Michael Weissenbacher <MWeissenbacher@n...>
wrote:
From my understanding, and experience using the API directly via c /
c++, using local verses TCP/IP connection sets up the DB internals
differently. When a connection is made using a local path, e.g.,
c:\database\test.gdb, the gds32.dll in turn runs under a single
threaded model, not the super-server model. Therefore if you attempt
to establish another connection to the database the second attempt
will deadlock. Your application will stop responding. Likewise if
you attempt to share this single connection among threads you will
also deadlock your application. However, when connection via the
TCP/IP connection, e.g., localhost:c:\database\test.gdb, the server
internally runs as a super-server and supports multithreaded
clients. You can then create a connection for each application
thread without the deadlock issue.
Please be aware I'm not claming any great knowledge of the DB
internals, I'm only sharing my experience and information that I
uncovered while asking the same question, correct or not!
Dan
--- In ib-support@y..., Michael Weissenbacher <MWeissenbacher@n...>
wrote:
> in my experience you get corrutions when you use differentconnection
> strings from different hosts. in fact it doesn't matter if you'reconnecting
> from different hosts, but it does matter if you use differentpaths. you
> should always check this by looking at the open databases (whichcan be
> listed for example with ib expert). one database should never belisted
> there multiple times.problem by
> i for example had the problem with:
> servername:/opt/interbase/databases/db.gdb and
> servername://opt/interbase/databases/db.gdb
>
> it seems that on linux (probably all unixes) you can avoid this
> creating a symlink to the db and always using this symlink. fb willresolve
> the symlink to the original file name which will guarantee thatalways the
> same path is used.realise
>
> regards
> mw
>
> -----Original Message-----
> From: rodbracher [mailto:rod@m...]
> Sent: Tuesday, October 15, 2002 12:43 PM
> To: ib-support@y...
> Subject: [ib-support] Re: Connection Strings
>
>
> I use IB6.0 - does this mean I could get a corruption with local vs
> remote connections ?
>
> Or were the corruptions you were talking about only on different
> remote connections ?
>
> --- In ib-support@y..., "Jason Chapman (JAC2)" <jason@j...> wrote:
> > I have never had a problem with local vs remote connections,
> although for a
> > couple of years now I have always connected remotely, even on the
> same
> > machine. On FB now, there should be no problem as the file is
> locked on
> > first connection, the problem used to be that if IB didn't
> that thehttp://docs.yahoo.com/info/terms/
> > DB was already open it would merrily open it again and internally
> think it
> > was looking at two DB's, resulting in near instant corruption.
> >
> > we had it with:
> >
> > server:d:\data\some.gdb vs
> > server: d : \data\some.gdb (notice the spaces).
> >
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@e...
>
>
>
> Your use of Yahoo! Groups is subject to