| Subject | Re: [firebird-support] Re: INET/inet_error: read errno = 10054 in localhost |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-01-29T00:12:56Z |
At 10:01 AM 29/01/2008, Federico Bobbio wrote:
"Session" is a client-side concept that represents the model of "a user application" connecting to "a database". In your fat client, you have:
1. Your client application code that runs on the client machine.
2. The Firebird API, which is loaded on the client machine as a library that exposes all the functions, macros, etc. that are needed for the client application to communicate with the Firebird server. On a Windows client machine, its name is fbclient.dll. On Linux SS, it is libfbclient.so.
3. Between the client application and the Firebird is a data access layer, such as a driver (e.g. Jaybird for Java, an ODBC driver, a .NET driver, a PHP or Python library, a set of Delphi components, a set of wrapper components such as IBPP for C++, and so on).
At its simplest, a "session" is one client that has made one connection to one database using one Database Parameter Block (DPB), having called one or more appropriate functions of the API. Each different, client-language-specific data access layer (see 3 above) has its own way to wrap up the DPB and the required API calls. Your application would call these wrappers and is not concerned about what the wrapper code does beneath the surface. When this call succeeds, you have "a connection".
Within the connection, you have transactions. A transaction isolates one block of work in your application from another block of work. It also isolates its "view" of database state from the "view" seen by any other transaction. That goes for different transactions within this session, as well as transactions within other sessions.
Within a transaction, you have statements. Each statement is isolated within one and only one transaction. A SELECT statement returns a SET to a buffer at the server. Rows from that buffer are fetched on request *within* the current execution of the statement and within the current transaction. Statements that are not SELECTs return data directly to the calling transaction.
So, to summarise the simple picture, a session consists of:
1 connection
a transaction
[one or many statements pertaining to that transaction]
[one or many sets and other results pertaining to that transaction]
another transaction
[one or many statements pertaining to that transaction]
[one or many sets and other results pertaining to that transaction]
another transaction ..... etc.
So, yes, I think at this point there is a LOT that you are missing. I strongly advise that you subscribe to the support list of whatever driver you are using for your data access layer and get some direction on how to manage the connections, transactions and statements in your client application. Visit http://firebirdsql.org/index.php?op=lists to find the right list.
To make it easier for the people whom you want to help you, please click the ASK SMART link at the top of that page and study the linked article, "How to Ask Smart Questions". It's essential for everyone who hasn't used support lists before...
./heLen
>> -- Is this a single-user, stand-alone system?Accessing databases as a local user via localhost is not a great way to develop a 2-tier fat client system that you intend to deploy for multi-user use. Since you are using XP, develop from a remote desktop client and use the node name of the server in your TCP/IP string. (IP address is also possible, if you can be certain that, when the system is deployed, you can be certain that the IP address will be statically defined.)
>> -- Is it 2-tier client server or n-tier? If it is 2-tier then
>remote clients cannot access a database through localhost...
>
>
>At this time is a single user in one computer, really simple, but in
>the future it should grow.
>The business and presentation tiers are managed in the client side (if
>i get you right)
>> Tell us more about "user disconnecting from the server".You can, however, develop and test it as a remote user. "Remote" means "in the same network as the server host, but on a different node".
>
>I'm developing the app and i didn't give it to the customer yet, so
>i'm the only user right now, the problem is that i can't make it work
>fine :(
>> >and a problem with the used SQL.Yes, even worse. :-(
>>
>> How long is a piece of string? Bad SQL can make response slow but
>it wouldn't directly cause a client connection to break...
>
>As i said i'm not an experienced user so i'll tell you how i'm working
>with SQL. For example i have an Employeers table and they hava Phones
>(table) and Addresses (table) and when i need to get the data i open a
>connection to get the info from the Employeers table, inside of this
>connection i open another for the phones and another for the
>addresses, is this as bad as it sounds? :P
>The querys are like "SELECT <COLUMN_NAMES> FROM <ONLY_ONE_TABLE> WHEREIt's not primarily about the size of the tables. SQL is a *query language*, which means it is designed to let you retrieve SETS. Your SELECT list and your WHERE clause determine (respectively) how many columns and how many rows are in your sets. When you go into a deployed client/server situation the size of the sets becomes a lot more important than it is when everything is happening on a single machine!
>EMPLOYEER_ID = X", this is just an example, there are no more than 10
>or 12 columns in the bigger tables
>> >Could the problem be that when i need data from multiple tables i'mHmmm, instead of trying to answer that question, perhaps it is better to try to get you to understand the concept of a "session".
>> >opening a lot of connections to get it?
>>
>> Yes. The client should have one connection per thread and the work
>within one thread should never refer to other connections or to
>transactions and statements in other connections.
>
>So i need to separate the connections in different threads or should i
>bring all the data i need in one big query?
"Session" is a client-side concept that represents the model of "a user application" connecting to "a database". In your fat client, you have:
1. Your client application code that runs on the client machine.
2. The Firebird API, which is loaded on the client machine as a library that exposes all the functions, macros, etc. that are needed for the client application to communicate with the Firebird server. On a Windows client machine, its name is fbclient.dll. On Linux SS, it is libfbclient.so.
3. Between the client application and the Firebird is a data access layer, such as a driver (e.g. Jaybird for Java, an ODBC driver, a .NET driver, a PHP or Python library, a set of Delphi components, a set of wrapper components such as IBPP for C++, and so on).
At its simplest, a "session" is one client that has made one connection to one database using one Database Parameter Block (DPB), having called one or more appropriate functions of the API. Each different, client-language-specific data access layer (see 3 above) has its own way to wrap up the DPB and the required API calls. Your application would call these wrappers and is not concerned about what the wrapper code does beneath the surface. When this call succeeds, you have "a connection".
Within the connection, you have transactions. A transaction isolates one block of work in your application from another block of work. It also isolates its "view" of database state from the "view" seen by any other transaction. That goes for different transactions within this session, as well as transactions within other sessions.
Within a transaction, you have statements. Each statement is isolated within one and only one transaction. A SELECT statement returns a SET to a buffer at the server. Rows from that buffer are fetched on request *within* the current execution of the statement and within the current transaction. Statements that are not SELECTs return data directly to the calling transaction.
So, to summarise the simple picture, a session consists of:
1 connection
a transaction
[one or many statements pertaining to that transaction]
[one or many sets and other results pertaining to that transaction]
another transaction
[one or many statements pertaining to that transaction]
[one or many sets and other results pertaining to that transaction]
another transaction ..... etc.
>Is a simple application for a company that sells medical products, itSeparate connections must be in different threads. Each connection must comprise a totally isolated session (its own transactions, statements, sets, etc.)
>should manage only information about the statistics of the sales.
>So i need to separate the connections in different threads
> or should i bring all the data i need in one big query?That's the wrong question to ask. For all of the data that the user needs to work with, all of the sets (output of SELECT statements) and executable statements (insert/update/delete) needed for a single task should be defined within the context of a single connection | transaction. If you make separate *connections* for each statement and then try to "hook them up" you will have access violations in the client. When the client crashes, the connection to the server is broken and you get the 10054 (and other) network errors that you are seeing.
So, yes, I think at this point there is a LOT that you are missing. I strongly advise that you subscribe to the support list of whatever driver you are using for your data access layer and get some direction on how to manage the connections, transactions and statements in your client application. Visit http://firebirdsql.org/index.php?op=lists to find the right list.
To make it easier for the people whom you want to help you, please click the ASK SMART link at the top of that page and study the linked article, "How to Ask Smart Questions". It's essential for everyone who hasn't used support lists before...
./heLen