struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chaikin, Yaakov Y." <>
Subject RE: Database Connection Workflow Question
Date Fri, 28 Jan 2005 17:16:27 GMT
Quote from the ServiceLocator Pattern about performance and JNDI:

Initial context creation and service object lookups, if frequently required,
can be resource-intensive and may impact application performance. This is
especially true if the clients and the services are located in different

-----Original Message-----
From: Chaikin, Yaakov Y. []
Sent: Friday, January 28, 2005 12:13 PM
To: 'Struts Users Mailing List'
Subject: RE: Database Connection Workflow Question


How long it takes to look up things through JNDI? Loooooooong is the answer.
That's even if your JNDI is sitting on the same machine as your servlet/EJB
container. But if it's a distributed environment... see you later. :)

As far as an administrator changing the DataSource while the application is
running... There are opportunities to take care of this without slowing your
application down for the rest of the time.

Of course, restart the app is one obvious choice, but if that's not an
option... then one solution that come to is to redirect all incoming traffic
to a different machine for the time being, change your datasource and then
allow traffic again.

I'd have to think about how to do this better if that's not an option for
whatever reason... But to always have to look up your DataSource through
JNDI just seems like a major slowdown just to take care of this one
situation where you would change the data source on the fly.

That's my understanding of the issue...


-----Original Message-----
From: Eddie Bush []
Sent: Friday, January 28, 2005 11:56 AM
To: Struts Users Mailing List; Larry Meadors
Subject: Re: Database Connection Workflow Question

I wouldn't even store the DataSource.  You may wish to have multiple
DataSource instances you wish to use in a given project.

I have Business Objects that extends a "BaseBO" object, which are
generated by a factory (the factory reads an XML file using digester).
 My DAOs are generated similarly.  My BO knows the "name" of the DAO
it needs to work and just calls it out by name, from the factory.

I treat my BOs and DAOs as "effective singletons".  By that I mean
there is never more than one instance created through the factory (the
class does not follow the singleton pattern though, since that works
against inheritance).  The DAO itself is configured to "know" the name
of it's datasource and passes this down into the bowels of my
SQL-execution subsystem that retrieves the apropriate datasource
instance and executes a given query.

How long does it really take to lookup a resource in JNDI?  Not very
... and it's conceivable it could change on the fly (the system admin
changes it through some admin tool, say).

On Fri, 28 Jan 2005 09:23:38 -0700, Larry Meadors
<> wrote:
> I would never reccommend storing a private connection object in a DAO
> - that is why we have DataSource objects. Get a connection, use it,
> close it, and keep the open time to a minimum. Using a DataSource, you
> can open and close connections for almost no cost (in terms of time).
> In addition, unit testing that kind of architecture is a major PITA
> because of the setup required.
> Larry

Eddie Bush

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message