Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database linger [CORE4263] #4587

Closed
firebird-issue-importer opened this issue Nov 12, 2013 · 16 comments
Closed

Database linger [CORE4263] #4587

firebird-issue-importer opened this issue Nov 12, 2013 · 16 comments

Comments

@firebird-issue-importer

Submitted by: @AlexPeshkoff

Votes: 1

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.

Commits: 120b10a FirebirdSQL/fbt-repository@7cec8fd

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Open [ 1 ]

Fix Version: 3.0 Alpha 2 [ 10560 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Commented by: Sean Leyne (seanleyne)

Alex,

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Commented by: @dyemanov

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: http://conferences.embarcadero.com/article/32257#DatabaseLinger

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Commented by: @asfernandes

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Commented by: Sean Leyne (seanleyne)

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Commented by: @dyemanov

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2013

Commented by: @mrotteveel

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 CORE4263?focusedCommentId=27322&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#⁠action_27322 ), in most systems this is handled using a connection pool inside the webapplication (or the application server).

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 13, 2013

Commented by: @AlexPeshkoff

Certainly this is not default. Linger is configured using ALTER DATABASE statement, i.e.

ALTER DATABASE SET LINGER TO 30; -- seconds
ALTER DATABASE DROP LINGER;

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 13, 2013

Commented by: @dyemanov

Does active linger allow or prohibit exclusive database operations, e.g. validation, drop database, etc?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 13, 2013

Commented by: @AlexPeshkoff

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 13, 2013

Commented by: @asfernandes

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?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 13, 2013

Commented by: @dyemanov

I believe the linger "caches" only the dbb (i.e. shared) state, not the per connection state. So context variables are not affected.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 13, 2013

Commented by: @AlexPeshkoff

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 14, 2013

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 27, 2014

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants