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.

asked 23 Jul '12, 14:46

Breck%20Carter's gravatar image

Breck Carter
26.8k420580826
accept rate: 20%

edited 23 Jul '12, 14:51

Mark%20Culp's gravatar image

Mark Culp
22.5k9129264

"needs-tagging" is a synonym for "abdicates-responsibility" :)

(23 Jul '12, 14:49) Breck Carter
Replies hidden

Done - I tagged it for you.

(23 Jul '12, 14:52) Mark Culp
1

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 :)

(23 Jul '12, 14:58) Mark Culp
Replies hidden

"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!).

(23 Jul '12, 17:16) Justin Willey
2

@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 :)

(27 Jul '12, 10:59) Breck Carter
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • 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:

×106
×35
×10
×2

question asked: 23 Jul '12, 14:46

question was seen: 1,831 times

last updated: 27 Jul '12, 10:59