in this case each instance of the application connects with the same user name, so could the server take all connections as a single one?

----- Original Message -----
From: Helen Borrie
To: ib-support@yahoogroups.com
Sent: Tuesday, January 29, 2002 8:52 PM
Subject: Re: [ib-support] Working with IB from an application running several times in Terminal Server


At 01:22 PM 29-01-02 -0300, you wrote:
>Let me explain a very particular case:
>
>We have our application running on a terminal server and about 20-30 users
>connect to it to use the same EXE file.
>
>The IBServer (in another machine) receives connections only from the
>terminal server, but it turns to work very slow in a couple of hours after
>most of the users connect to the system. (the same application working
>without terminal server on other customers doesn't show that poor
>performance).
>
>We've been thinking about the way in which IB and FB (we've used both)
>identifies a session in memmory, because the server starts gaining memmory
>and never releases it until the last user closes the application.
>
>So... could it be possible that IB manages the session information with all
>the transactions information as it is only one user connected and working
>all day long??? Does anybody know how IB keep the info per session???

IB doesn't manage sessions, it manages connections. You can find out the user names associated with connections but nothing else.

Transactions are started and committed by the client application. The server doesn't know anything about ownership of transactions.

>does
>it identify it by host name and application name ?? (in that case it would
>be in trouble).

No.


>Any comments will be useful, thanks

Seeing the symptoms you describe, I would look first at the possiblility that you have many long-running transactions that never get committed, thus inhibiting garbage collection in the database.

You can query the database statistics using the command-line utility gstat. Look for big differences between the Oldest Interesting/Oldest active transactions and the Next Transaction. Documentation for gstat is in the OpGuide.pdf manual.

Another angle is the possibility that you have the database running on an XP server. Do you? in this case, you do have a known problem regarding this OS.

The database shouldn't slow down or behave as you describe, so the problem is in your application or your environment. If you post more information about how the client application works and the platform, development tools, etc., more people may be able to offer more advice.

regards,
Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________


Yahoo! Groups Sponsor


------------------------------------------------------------------------



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]