| Subject | Re: [firebird-support] *.FDB Lock Not Released when Process Shuts Down |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-07-20T00:08:46Z |
At 04:27 PM 19/07/2005 +0000, you wrote:
The file lock on the database file won't be released until there are no
connections left.
When you say "our application process is shutdown", presumably you are
talking about an application that is doing something and, at some point,
requests a detach.
When the server gets that request, a wind-down process begins. Ideally,
your application will have already taken care of ensuring that all active
transactions are cleanly committed or rolled back, before it submits the
detach request. If any transactions are still in the process of
completing, the detach will wait until they are done. If any transactions
are waiting for resolution of a conflict and your application code isn't
resolving that conflict, then you have left unfinished business for the
server to attend to.
In cases where the application (or some other application) has not
requested the ending of transactions, there will be a delay (sometimes
long) while the server waits for them to time out. For those transactions,
it will then have some jobs to do with any new record versions that are
sitting around belonging to those transactions.
All that aside, if someone on the system is running some other application
over the database - a DB admin tool or backup, for example, then the
shutting down of your application won't cause a database shutdown at all,
because it is not the last connection to detach.
If the sweep interval is set to a non-zero value, it's also possible that a
sweep is running at the time the detach request is made. Even if your
application has completed its detach, the sweep thread may still be busy.
doing what it has to do. If it's a problem from *your* point of view, i.e.
you have some pressing reason why you can't wait for the cleanup, then your
"troubleshooting" would be to investigate the application code and the
network to find out what is causing the cleanup to take longer than you
want it to.
./heLen
>Our project is using FB 1.5 as a backend for a general loggingAssuming you are using Superserver...
>application. We've come across an issue where when our application
>process is shutdown that the FB Server does not let go of the lock on
>the database file.
The file lock on the database file won't be released until there are no
connections left.
When you say "our application process is shutdown", presumably you are
talking about an application that is doing something and, at some point,
requests a detach.
When the server gets that request, a wind-down process begins. Ideally,
your application will have already taken care of ensuring that all active
transactions are cleanly committed or rolled back, before it submits the
detach request. If any transactions are still in the process of
completing, the detach will wait until they are done. If any transactions
are waiting for resolution of a conflict and your application code isn't
resolving that conflict, then you have left unfinished business for the
server to attend to.
In cases where the application (or some other application) has not
requested the ending of transactions, there will be a delay (sometimes
long) while the server waits for them to time out. For those transactions,
it will then have some jobs to do with any new record versions that are
sitting around belonging to those transactions.
All that aside, if someone on the system is running some other application
over the database - a DB admin tool or backup, for example, then the
shutting down of your application won't cause a database shutdown at all,
because it is not the last connection to detach.
If the sweep interval is set to a non-zero value, it's also possible that a
sweep is running at the time the detach request is made. Even if your
application has completed its detach, the sweep thread may still be busy.
>Has anyone experienced a similar issue or might have suggestions forIt's not really a "problem", from the db server's point of view. It's only
>troubleshooting/fixing the problem?
doing what it has to do. If it's a problem from *your* point of view, i.e.
you have some pressing reason why you can't wait for the cleanup, then your
"troubleshooting" would be to investigate the application code and the
network to find out what is causing the cleanup to take longer than you
want it to.
./heLen