| Subject | Re: [firebird-support] Re: How to detect a dead-lock? |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-12-24T10:54:56Z |
At 08:22 PM 24/12/2007, you wrote:
Some background information (assumng Linux, from your email header):
1. The "Classic" model (on Linux) consists of one instance of the executable process fb_inet_server that will be started by the xinetd daemon if a client succeeds in making a connection to a database.
-- You cannot make this type of connection if you do not supply a network path to the database.
-- You can use either libfbclient.so or libfbembed.so as your client here. libfbclient.so is the generic client-only client component. libfbembed.can be used for this style of connection if you use the TCP/IP local loopback server (localhost, or IP 127.0.0.1). In this context, only the client part of libfbembed.so is used.
2. Alternatively, an *embedded* Classic process on Linux can be created by using the libfbembed.so component as both client and server, by providing a local path to the database, i.e., with no IP address or servername in the connection string. In this context, a Classic process is started within the libfbembed.so component that connects directly AND EXCLUSIVELY to the database file.
This is not a "deadlock": it is a device lock. A database is a device. It can be connected to by only one server. While active, the embedded server has a device lock that prevents xinetd or another embedded server instance from making a connection. To end this lock, detach this connection. Then, xinetd will be able to make connections for your network client requests.
Please study the Quick Start Guide.
./heLen
>Dear,You are not giving us any useful information.
> It seems like not a dead-lock.
>I can not shut the database with fbmgr,The fbmgr tool is not used for managing Classic processes. It provides an interface for stopping/starting/restarting the executable program fbserver, that is the server component of the Superserver model.
>either.
>Just hung.We cannot tell what "hung" means.
Some background information (assumng Linux, from your email header):
1. The "Classic" model (on Linux) consists of one instance of the executable process fb_inet_server that will be started by the xinetd daemon if a client succeeds in making a connection to a database.
-- You cannot make this type of connection if you do not supply a network path to the database.
-- You can use either libfbclient.so or libfbembed.so as your client here. libfbclient.so is the generic client-only client component. libfbembed.can be used for this style of connection if you use the TCP/IP local loopback server (localhost, or IP 127.0.0.1). In this context, only the client part of libfbembed.so is used.
2. Alternatively, an *embedded* Classic process on Linux can be created by using the libfbembed.so component as both client and server, by providing a local path to the database, i.e., with no IP address or servername in the connection string. In this context, a Classic process is started within the libfbembed.so component that connects directly AND EXCLUSIVELY to the database file.
This is not a "deadlock": it is a device lock. A database is a device. It can be connected to by only one server. While active, the embedded server has a device lock that prevents xinetd or another embedded server instance from making a connection. To end this lock, detach this connection. Then, xinetd will be able to make connections for your network client requests.
Please study the Quick Start Guide.
./heLen