|
Perhaps optionally, the dbsrv process should not return control to dbspawn until the DatabaseStart event has finished. Stuffing all sorts of startup logic into the DatabaseStart event may become a trend, and if so, it may not even be desirable to proclaim "Now accepting requests", let alone allow dbspawn to let go, before that logic is finished. |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 23 Jul '12, 14:46
question was seen: 3,025 times
last updated: 27 Jul '12, 10:59
"needs-tagging" is a synonym for "abdicates-responsibility" :)
Done - I tagged it for you.
Interesting idea. At times I have thought that the database should not accept requests until the database start event had finished, but I had not extended that to not responding to dbspawn (aka the client that auto-started the server).
Can you provide some situations when this feature would be useful? I.e. what type of operations are you doing in the DatabaseStart event that would require the postponing of the response to dbspawn?
Would this feature need to be on a per-database basis? (e.g. I start two databases: the first has a databasestart event which needs to be complete before the server can be officially consider "ready", and the second I don't care about)... or is it sufficient to be a server-wide setting: wait for all databases on the command line to be "ready" or wait for none (current behaviour)?
As always, thanks for your suggestion :)
"At times I have thought that the database should not accept requests until the database start event had finished"
I do think that would be a good idea - there is the problem of course of what if it gets stuck (similar to the old one of what happens if the db start event disables connections!).
@Mark: Somehow I missed your comment until today...
In my case, all sorts of initialization logic is located inside the DatabaseStart event, and if the server releases control to dbspawn then other command(s) in the batch file can run and start pounding the server with client requests that cannot be satisfied until the DatabaseStart event completes... with custom logic being required to enforce the "cannot be satisfied until" requirement.
This request is part of the bigger issue: Other connections should not be allowed to run at all until the DatabaseStart event is complete... by definition, IMO, the database has not "started" until DatabaseStart completes.
The "gets stuck" argument is strawman... this request should not be rejected because it might adversely affect buggy DatabaseStart code that has been deployed into production.
However, I do realize that argument has been successful before; e.g., web functions cannot invoke web services on the same database for fear that someone might accidentally code an infinite loop. Offensive as it seems, perhaps we ARE all foolish ignorant children who need a nanny to guide us :)