On Thu, Jun 30, 2011 at 1:36 AM, V G <x.solarwind.x@gmail.com> wrote:

> Modern servers can handle MANY connections. I'll have to *try* to make it
> crash.
>

That is probably the most easy thing to do. That is called denial of servic=
e
attack (DoS). Software manufacturers has a hard time when they need to
protect their servers agains these kind of attack and attackers has to do
nothing serious or fancy just for example open as many connections to the
server as possible in a certain amount of time.

That is ok to say that you are not trying to do this, but actually software
bug. And we are engineers, we know there is no perfect software. No matter
how hard you try to write one, or how much experience or knowledge you have
on this field. However, good practices can reduce errors and makes it more
unlikely that your code is doing something terrible. So even for small apps
it is a good habit to do things right, and you were in the right track
asking for good habits doing these.

Some example can be like not closing the application or shutting down the
operating system, or losing net connection (wifi is pretty good at it), or
anything like that can cause that the SQL server still things that the
client is still connected, so it keeps the connection alive, while acceptin=
g
other incoming connections -- the client had been restarted or the net
connection came back and the db connection re-established, which can be a
new connection request. So while you think you opened one connection only,
the server thinks there are many. So here you go, you never know when and
why things went wrong, and these kind of things are really hard to debug --
maybe happens once in a blue moon when the secretary wears her blue scarf
while drinking mint tea.

One other issue I forgot to mention: If you keep a connection open, you
still need to handle errors, like if the connection lost. It can be of
several reasons, maybe the SQL server will close it after certain time of
inactivity or network error. So no matter what you will end up checking DB
connections and closing/reopening them when lost them, even if you decide
keep connections alive for longer period. This kind of things are done by
the connection pool, so why would we not using these, right? ;-)

Anyway, sorry for the long explanation, just wanted to answer the question
"What could possibly go wrong", and the correct answer is: "Everything".

Tamas




>
> > FAMOUS LAST WORDS!
>
> I hate when people say that. You can expect with a reasonable level of
> certainty that whatever you're working with won't crash as long as you're
> operating within its specifications. That's they key.
>
> And I am operating within specifications.
>
> I was only asking about good/bad/general coding styles for database
> programs
> and how it's *generally* done.
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



--=20
int main() { char *a,*s,*q; printf(s=3D"int main() { char *a,*s,*q;
printf(s=3D%s%s%s, q=3D%s%s%s%s,s,q,q,a=3D%s%s%s%s,q,q,q,a,a,q); }",
q=3D"\"",s,q,q,a=3D"\\",q,q,q,a,a,q); }
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.