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
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: Sean Leyne (seanleyne) Alex, Please elaborate on this further, the current details don't convey much. |
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 |
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. |
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. |
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. |
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). |
Commented by: @AlexPeshkoff Certainly this is not default. Linger is configured using ALTER DATABASE statement, i.e. ALTER DATABASE SET LINGER TO 30; -- seconds 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. |
Commented by: @dyemanov Does active linger allow or prohibit exclusive database operations, e.g. validation, drop database, etc? |
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. |
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? |
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. |
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,... Real code is a certainly more complex, but actually this is linger implementation. |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
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
The text was updated successfully, but these errors were encountered: