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 tiers
-----Original Message----- From: Chaikin, Yaakov Y. [mailto:[EMAIL PROTECTED] Sent: Friday, January 28, 2005 12:13 PM To: 'Struts Users Mailing List' Subject: RE: Database Connection Workflow Question Eddie, 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... Yaakov. -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
