Question about destructor of database and multiple use access
Dechcaudron via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu Jul 28 07:33:26 PDT 2016
I don't know anything about the driver you are using, but from my
general experience with DBs I'll try to give you some insight.
On Thursday, 28 July 2016 at 14:01:45 UTC, Suliman wrote:
> 1. Should declaration of them be field of class?
I'd say so. If you intend to use each instance of the class for
more than db operation (which you probably do), you'll probably
want to keep the connection alive between method calls,
connecting in the constructor. As for the statement, I don't
really know what it is about.
> 2. Should I call destructor and how it's should like?
You certainly want to close the connection to the db. Basically,
the destructor is intended to free resources such as dynamic
memory, closing connections... the GC will take care of dynamic
memory, but closing the connection to the DB is up to you. So do
that in the destructor. As for the rest of the fields, I don't
know if manual cleanup will be required, sorry.
> 3. If I will not call it would it wrong?
It would go wrong. Each instance would open a connection to the
DB and it would never be closed, which is a very bad thing. The
open connections would go adding up until the DB would not be
able to accept anymore connections and would probably refuse to
function.
> 4. If 100 users will come to my site, my code will open 100
> connections? And would open every new connection for every
> request? Can I open single connection and use it for all users?
It depends where you use this class and how you use it. If you
create an instance upon receiving a network request, a connection
would be open for each request, then closed in the destructor. So
if 100 users go to your site and they all start sending requests
at the same time, each request would open a db connection.
If you want to avoid this, either process the requests
sequentially (I don't recommend this) and create and instance of
this class beforehand, which you will use for all of them. If you
don't want to do sequential processing (which is likely your
case), and you still want to keep connections to a minimum,
create a shared instace of GDB and use it across the threads in
which requests are processed (syncronization will be required).
If you want to avoid syncronization issues while still
maintaining the benefits of shared instances, you could go with
an instance pool [1]. But opening connections upon request
receiving is not -that bad-, especially for a start, so long as
the maximum number of connections doesn't exceed a certain limit.
But I'd go with the pool.
As for the
> scope(exit) conn.close();
you don't have to worry about that so long as you manage it in
the destructor. If you don't, and open the connection in a
method, that line would go right after the connection opening, so
you ensure it is close upon scope exit.
Cheers!
[1] https://en.wikipedia.org/wiki/Object_pool_pattern
More information about the Digitalmars-d-learn
mailing list