Prev: Initializing Variables
Next: Whither JDK 7?
From: Rhino on 25 May 2010 16:55
This is probably going to sound awkward due to my lack of vocabulary so
please forgive me....

I have a project that has 21 classes in it that do various things to do
with generating my resume. (It generates the resume in a variety of
formats like HTML, PDF, Word, etc. etc.) There is basically what I would
have called a "mainline" in my COBOL days - I suppose we might call it a
driver these days? - that kicks everything off.

Now, a few of the classes need database access - for example, I store
information about references there - and several of the classes have the
potential of generating log messages.

I'm trying to figure out when I should initialize the logging and
database connection.

I'm leaning toward getting my database connection in the constructor of
the "mainline" and then passing that connection to each of the classes
that needs it as it is invoked in the mainline. I'm also leaning toward
getting my logger during the constructor of the mainline and, again,
passing it to each of the classes kicked off by the mainline.

This ensures that both the connection and logger are available to any
class that needs it. I'm also thinking that if creating the logger or
getting the database connection is a problem, I should probably find out
right at the start and probably abort the whole program if either one has
a problem. I'm inclined to think that if I'm unable to generate log
messages when I want to write them, that I shouldn't even get started.
The database connection is a little less categorical; if it is not
available, I could conceivably generate the resumes and simply display a
message to say that the references are not currently available so try
again later.

On the other hand, there are some classes that won't ever need to log -
little convenience classes that don't have any reason to throw exceptions
- and some of the work could be done even without the database connection
being there. Also, an argument might be made to the effect that the
classes that need database access (or even the logger) could simply
create their own _when needed_. That would also simplify the code
somewhat; if I do create the logger and database connection right at the
start and pass them to each and every class, then I add two extra
parameters to each constructor making more clutter than may be viewed as
strictly necessary.

What do you folks do in comparable situations?

I have a feeling I'm thinking of this too much like a COBOL programmer
and not enough like an OO/Java programmer.....

--
Rhino
From: Arne Vajhøj on 25 May 2010 17:40
On 25-05-2010 16:55, Rhino wrote:
> This is probably going to sound awkward due to my lack of vocabulary so
> please forgive me....
>
> I have a project that has 21 classes in it that do various things to do
> with generating my resume. (It generates the resume in a variety of
> formats like HTML, PDF, Word, etc. etc.) There is basically what I would
> have called a "mainline" in my COBOL days - I suppose we might call it a
> driver these days? - that kicks everything off.
>
> Now, a few of the classes need database access - for example, I store
> information about references there - and several of the classes have the
> potential of generating log messages.
>
> I'm trying to figure out when I should initialize the logging and
> database connection.
>
> I'm leaning toward getting my database connection in the constructor of
> the "mainline" and then passing that connection to each of the classes
> that needs it as it is invoked in the mainline. I'm also leaning toward
> getting my logger during the constructor of the mainline and, again,
> passing it to each of the classes kicked off by the mainline.
>
> This ensures that both the connection and logger are available to any
> class that needs it. I'm also thinking that if creating the logger or
> getting the database connection is a problem, I should probably find out
> right at the start and probably abort the whole program if either one has
> a problem. I'm inclined to think that if I'm unable to generate log
> messages when I want to write them, that I shouldn't even get started.
> The database connection is a little less categorical; if it is not
> available, I could conceivably generate the resumes and simply display a
> message to say that the references are not currently available so try
> again later.
>
> On the other hand, there are some classes that won't ever need to log -
> little convenience classes that don't have any reason to throw exceptions
> - and some of the work could be done even without the database connection
> being there. Also, an argument might be made to the effect that the
> classes that need database access (or even the logger) could simply
> create their own _when needed_. That would also simplify the code
> somewhat; if I do create the logger and database connection right at the
> start and pass them to each and every class, then I add two extra
> parameters to each constructor making more clutter than may be viewed as
> strictly necessary.
>
> What do you folks do in comparable situations?
>
> I have a feeling I'm thinking of this too much like a COBOL programmer
> and not enough like an OO/Java programmer.....

Both logging and database are rather well known problems with well known
solutions.

For logging I would say no central initialization at all, but let
the logging stuff read the configuration file at first call and
initialize.

For database you can either do something similar like have the
create connection code read the database configuration when needed
or if it is a heavy multithreaded app (does not sound like it) then
use a connection pool. A connection pool could also be initialized
at demand, but iy would be easier to justify initializing that at
startup.

Arne



From: Lew on 25 May 2010 19:07
Rhino wrote:
>> Now, a few of the classes need database access - for example, I store
>> information about references there - and several of the classes have the
>> potential of generating log messages.
>>
>> I'm trying to figure out when I should initialize the logging and
>> database connection.

You initialize logging via the framework, but you initialize a logger
separately for each class, or perhaps each instance.

You initialize the database setup when you load the driver, once, but not the
connections.

>> I'm leaning toward getting my database connection in the constructor of
>> the "mainline" and then passing that connection to each of the classes
>> that needs it as it is invoked in the mainline. I'm also leaning toward
>> getting my logger during the constructor of the mainline and, again,
>> passing it to each of the classes kicked off by the mainline.

No.

Loggers are essentially self-initializing when the Logger class initializes.
Likewise the database driver. But not individual logger instances and not
individual DB connections.

>> This ensures that both the connection and logger are available to any
>> class that needs it. I'm also thinking that if creating the logger or
>> getting the database connection is a problem, I should probably find out

DB connections can drop at any time. Past checks are no guarantee against
future exceptions.

>> right at the start and probably abort the whole program if either one has
>> a problem. I'm inclined to think that if I'm unable to generate log
>> messages when I want to write them, that I shouldn't even get started.

The logging framework does that already.

>> The database connection is a little less categorical; if it is not
>> available, I could conceivably generate the resumes and simply display a
>> message to say that the references are not currently available so try
>> again later.

There is a difference between initializing the database driver and using a
particular connection. You don't really need to create one and only one
connection yourself - that's what a connection pool handles for you.

Don't reinvent the wheel.

I also don't know if connections can be managed very well if they're being
used all over the place at once. The recommended pattern is to obtain one,
use it and close it right away to release resources held by Statements and
ResultSets and the like. For example, how would you interleave separate
transactions? What if you needed different transaction isolation?

Arne Vajhøj wrote:
> Both logging and database are rather well known problems with well known
> solutions.
>
> For logging I would say no central initialization at all, but let
> the logging stuff read the configuration file at first call and
> initialize.
>
> For database you can either do something similar like have the
> create connection code read the database configuration when needed
> or if it is a heavy multithreaded app (does not sound like it) then
> use a connection pool. A connection pool could also be initialized
> at demand, but iy would be easier to justify initializing that at
> startup.

Connection pools are essentially self-initializing - you use a pooling driver
and then just pretend each new connection really is new and not recycled.

--
Lew
From: Arne Vajhøj on 25 May 2010 20:33
On 25-05-2010 19:07, Lew wrote:
> Arne Vajhøj wrote:
>> For database you can either do something similar like have the
>> create connection code read the database configuration when needed
>> or if it is a heavy multithreaded app (does not sound like it) then
>> use a connection pool. A connection pool could also be initialized
>> at demand, but iy would be easier to justify initializing that at
>> startup.
>
> Connection pools are essentially self-initializing - you use a pooling
> driver and then just pretend each new connection really is new and not
> recycled.

It can be self initializing like logging, but occasionally the
pool is initialized at startup.

In some server contexts that is good for response time for the
first user, because initializing a connection pool can take
some time.

Arne

 | 
Pages: 1
Prev: Initializing Variables
Next: Whither JDK 7?