Issue Details (XML | Word | Printable)

Key: CORE-4263
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 1
Watchers: 1

If you were logged in you would be able to see more operations.
Firebird Core

Database linger

Created: 12/Nov/13 10:55 AM   Updated: 27/Mar/14 11:58 AM
Component/s: None
Affects Version/s: None
Fix Version/s: 3.0 Alpha 2

 Description  « Hide
In case of a lot of attach/detach operations to database closing it (when last attachment is gone) after some delay is an efficient performance optimization.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 12/Nov/13 04:29 PM

Please elaborate on this further, the current details don't convey much.

Dmitry Yemanov added a comment - 12/Nov/13 04:45 PM
AFAIU, the idea is to keep the database internally attached (for the configured time interval) even after the last user connection had gone. It allows to serve connections faster if they frequently come and go away (common for many web apps, for example) due to the already held locks and the page cache being warm. See also:

Adriano dos Santos Fernandes added a comment - 12/Nov/13 04:51 PM
I think this should be done when configured then, i.e., not by default.

For the web case, it would be a bad practice to work this way, as it's common to maintain a database pool that avoids this problem.

Sean Leyne added a comment - 12/Nov/13 04:59 PM
I agree with Adriano, this should not be the default modality.

From our usage, we expect that if there are no database connections that the database file is available for OS level operations. This feature would invalidate that expectation.

Dmitry Yemanov added a comment - 12/Nov/13 05:17 PM
So far I haven't seen indications that this feature will be turned on by default. And I agree with you on this point.

Sean, I don't know your details but I'd call such an expectation unreliable in the general case. It's hard to guarantee that no new connection can jump in right after you checked the server for having no connections. gfix -shut should be a solution in this case and I suppose it will shutdown the active linger as well.

Mark Rotteveel added a comment - 12/Nov/13 06:10 PM
If this is implemented, also consider what would happen if a drop database is issued through a service request (as the database would be 'in use').

Also the suggestion that this is for webapps which open and close connections (in comment ), in most systems this is handled using a connection pool inside the webapplication (or the application server).

Alexander Peshkov added a comment - 13/Nov/13 06:06 AM
Certainly this is not default. Linger is configured using ALTER DATABASE statement, i.e.


Certainly any kind of shutdown terminates linger state. Moreover, if one needs to forcibly close database not shutting down it (for example - to release server's resources) we will have -nolinger switch in gfix which makes database close once when last attachment is gone, appropriate services API and certainly tag in DPB which actually does the work.

Setting linger to non-zero value for security database (located on raid0 disk with ext3 having barriers turned on) makes attach/detach test run ~8% faster when SRP is used.

Dmitry Yemanov added a comment - 13/Nov/13 06:47 AM
Does active linger allow or prohibit exclusive database operations, e.g. validation, drop database, etc?

Alexander Peshkov added a comment - 13/Nov/13 08:07 AM
Drop database is incompatible with active linger. To drop database you should have an attachment to it - therefore when you execute DROP DATABASE database is not in linger state. And certainly when drop database is complete there is nothing to go into linger state.

Same for validation - when doing it we have exclusive attachment. When validation is complete, database will go to linger state.

Adriano dos Santos Fernandes added a comment - 13/Nov/13 09:58 AM
If a connection is closed and database goes to linger, then a connection is made, does the previous database state (say, session context variables) will go to the new connection or not?

Dmitry Yemanov added a comment - 13/Nov/13 10:12 AM
I believe the linger "caches" only the dbb (i.e. shared) state, not the per connection state. So context variables are not affected.

Alexander Peshkov added a comment - 13/Nov/13 10:37 AM
I believe a lot of questions will be gone after publishing this small fragment of patch

Index: src/jrd/jrd.cpp

@@ -6389,6 +6413,...
    if (dbb->dbb_attachments)
        return false;
+ // Database linger
+ if ((flags & SHUT_DBB_LINGER) && // flags is a parameter, passed to shutdown_database() instead 'bool release_pools'
+ (!(engineShutdown || (dbb->dbb_ast_flags & DBB_shutdown))) &&
+ (dbb->dbb_linger_seconds > 0) &&
+ dbb->dbb_config->getSharedCache())
+ {
+ if (!dbb->dbb_linger_timer)
+ {
+ dbb->dbb_linger_timer = new Database::Linger(dbb);
+ }
+ dbb->dbb_linger_timer->set(dbb->dbb_linger_seconds);
+ return false;
+ }

Real code is a certainly more complex, but actually this is linger implementation.