| Subject | Re: [firebird-support] Re: How to shutdown Firebird server ? |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-04-15T00:32:23Z |
At 05:18 AM 15/04/2008, Jocelyn Bernier wrote:
a) Close/kill mean the same thing with a process that is meant to run as a service. The process itself knows what to do to terminate gracefully when instructed to do so. Close/kill are not the same as "crash". If you have something beyond the control of the process that causes it to terminate abnormally, such as a dangerous UDF, then the process usually cannot terminate gracefully.
b) An application designed to run as a service is expected to be available whenever a client requests the service. Whether the service is being run in the services space (as when installed as a service) or in the user's space (as when installed as an application), it still knows how to shut down gracefully.
If they don't get the message, or ignore it, then they risk losing any uncommitted work.
But - if it's 3-tier then the clients aren't connected to the database, are they? This is the place everything is controlled, including knowledge of any live attachments...why not put the shutdown messages and operations there?
Running a Firebird server -- and indeed your application server -- as an application is justified if the host machine is Win98, since it doesn't support services. It's justified (maybe) on a stand-alone system where there might be reasons why the embedded server can't be used. But here you have a 3-tier architecture so we are not looking at a stand-alone system...
If a database client gracefully closes its attachment then what happens on the disconnection request depends entirely on what the application does in response. Maybe it rolls back any uncommitted work, or commits it. If the application doesn't do either, then the Firebird server would eventually treat those transactions as "dead" and clean them up. Whatever happens, they won't be picked up in future and treated as though they were not dead.
Or does it mean the Windows user in whose application space you are running the Firebird server and/or the application tier.
Or what?
It does look as though your application tier is providing some level of marshalling protection. If you're not the author of the software then it does seem that you need to consult the author and find out how things work in that setup....maybe a graceful exit is already built into that application layer and you just need to find out how to work it?
./heLen
>> 1. I have a server [host machine] running Firebird [Superserver] in application mode (-a switch).Comments:
>
>> 2. During the night some maintenance [unrelated to Firebird] needs to be done on that server [machine].
>
>> 3. Before the maintenance start I need to close the Firebird
>server [process] and restart it at the end.
>
>> 4. I don't want to kill the Firebird process because I don't want
>to corrupt my databases, I want to close it cleanly.
> For me closing the Firebird (or applications) is not the same thing as killing the process. Killing a process in Windows can produce bad results if the application doesn't close by itself.
a) Close/kill mean the same thing with a process that is meant to run as a service. The process itself knows what to do to terminate gracefully when instructed to do so. Close/kill are not the same as "crash". If you have something beyond the control of the process that causes it to terminate abnormally, such as a dangerous UDF, then the process usually cannot terminate gracefully.
b) An application designed to run as a service is expected to be available whenever a client requests the service. Whether the service is being run in the services space (as when installed as a service) or in the user's space (as when installed as an application), it still knows how to shut down gracefully.
>> b) Why do you think that killing/closing/terminating the FirebirdThat is true whether you are running Firebird as a service or as an application.
>[server] process would corrupt databases?
>>
>
>Because I don't know if all the requested actions have been done by
>Firebird. So killing the process while Firebird is working is not a
>good idea.
>> 5. I know there is already a way to shutdown the database onlygfix is itself an application, a set of tools that operates on databases. It doesn't operate on other processes. When you want to close/kill the server process (whether service or application!) you need to shut down the databases FIRST. When a database is successfully "shut down" it is flagged "offline" in its header. The server process will not accept any new connections or allow any new transactions to start from ordinary users while the database is flagged offline.
>but how to do with fbserver.exe ?
>>
>> -- You don't do it with fbserver.exe, you do it with gfix.
>Sorry I wrote this because I saw nothing like this with gfix so I
>thought it could be with fbserver.exe like when I started the
>Firebird with the -a.
>Exactly how you do it dependsFirebird 2 gives you a number of different shutdown states - see the release notes. If you are going the stop the Firebird server process then you want to specify the FULL state.
>>
>> (a) on what version of Firebird you are running [Firebird 2.0]
>Nobody should be working on the Firebird at that time but I don'tThe gfix -shut command takes a timeout value in seconds. When you are going to shut down a database, you should send a message out to all the users announcing that it is going to happen and instructing them to commit all changes and log out. How you do this is up to you - the Firebird server process doesn't have a way to communicate with them.
>want to take the chance.
If they don't get the message, or ignore it, then they risk losing any uncommitted work.
>given that you said before that you can't run Firebird as a service,So why do you have to run the Firebird server as an application? You are forcing the site to keep the host machine open and logged in as Administrator even at night when you don't know who is around.
>do we assume therefore that the host machine is running Windows 98?
>>
>No the host machines are running Windows 2003, Windows 2000 and in
>the worst case, Windows XP. They are also going to Vista :-(
>> The users are 3-tier.That's another strong reason NOT to run the Firebird server as an application.
But - if it's 3-tier then the clients aren't connected to the database, are they? This is the place everything is controlled, including knowledge of any live attachments...why not put the shutdown messages and operations there?
>> 7. Because you have to ask this question at all, must we assumeYou have an unknown number of people working late, using services that are insecure....
>that you have users connected and working on databases at the time
>you want to kill the Firebird server process? Yes or No?
>>
>
>Should not but we never know. Sometime people work late.
>I already analyzed all that but to be safe I thought it would beProblems get to be complicated when there's not enough information.
>easy to shutdown the Firebird. If I would have installed it as
>service I would have just stopped it. But per what I see this look
>very complicated. Why ?
Running a Firebird server -- and indeed your application server -- as an application is justified if the host machine is Win98, since it doesn't support services. It's justified (maybe) on a stand-alone system where there might be reasons why the embedded server can't be used. But here you have a 3-tier architecture so we are not looking at a stand-alone system...
>> -- you can test whether anyone is logged in to a database byYou can't rename a file if it is open. A database file is open if there is at least one client attached. With a 3-tier setup, the jury stays out. Maybe the application layer stays connected constantly...in which case, only that application "knows" whether it has any live clients and the "renaming" trick won't work until the application tier is shut down (closed/killed, choose your own word!)
>attempting to rename the database file. If it works, then nobody is
>logged in and the database is *already* shut down. You can just go
>to Task Manager and stop the Firebird process.
>>
>
>That mean all the Firebird jobs have been done ?
If a database client gracefully closes its attachment then what happens on the disconnection request depends entirely on what the application does in response. Maybe it rolls back any uncommitted work, or commits it. If the application doesn't do either, then the Firebird server would eventually treat those transactions as "dead" and clean them up. Whatever happens, they won't be picked up in future and treated as though they were not dead.
>That could explain why I can an error message when the users"Users"? Does this mean clients of the application tier? (which would be STRANGE!)
>shutdown their Windows. A message say that there is still users
>connected to Firebird and don't want to close.
Or does it mean the Windows user in whose application space you are running the Firebird server and/or the application tier.
Or what?
It does look as though your application tier is providing some level of marshalling protection. If you're not the author of the software then it does seem that you need to consult the author and find out how things work in that setup....maybe a graceful exit is already built into that application layer and you just need to find out how to work it?
./heLen