Dave Tolls wrote:The constructor won't get called every time.
So something else is going on.
I would debug this by sticking a breakpoint in the constructor at the start and then seeing where it is getting called.
Dave Tolls wrote:The constructor won't get called every time.
So something else is going on.
I would debug this by sticking a breakpoint in the constructor at the start and then seeing where it is getting called.
Bear Bibeault wrote: No! In fact, keeping a connection open for a microsecond longer than it needs to be is an extremely bad practice. Open the connection, get your data, copy it to model constructs, then close the connection as soon as possible.
Steve Dyke wrote:
Are there any acceptations to this rule?
Bear Bibeault wrote:More: your connection should not be created in a servlet, stored in a session, or exist anywhere else in the control or View layers. It should only exist in the model.
Look into container managed connection pools; that's the best practice.
Bear Bibeault wrote:Use container-managed connection pooling. Anything else is a hack by comparison.
Steve Dyke wrote:I was under the impression that this was container managed connection pooling. Connection pooling is set up on app server and my app references the JNDI name of the connection pool.
Paul Clapham wrote:
Steve Dyke wrote:I was under the impression that this was container managed connection pooling. Connection pooling is set up on app server and my app references the JNDI name of the connection pool.
No. Lines 10, 11, and 64 are what you need to use container-managed connection pooling. Connect to the container, get a data source, get its Connection object. All the rest of your code should be replaced by data managed by the container. And yes, you can put all of those parameters into the connection pool's configuration.
Paul Clapham wrote:Proposed code to get database connection:
Paul Clapham wrote:This code:
What's that all about? Is there some possibility that somebody might sneak in and break your container's JNDI configuration? What you've got in the directConnect() method is totally unnecessary in my opinion and I would get rid of it. Just have that catch-block do something which will make sure that responsible people in the back room get notified and make sure that the user gets told that there's something wrong with the system.
Paul Clapham wrote:Proposed code to get database connection:
Paul Clapham wrote:Proposed code to get database connection:
Paul Clapham wrote:Yes, that's pretty close. Only I wouldn't catch the Exception and essentially ignore it, since then a NullPointerException is going to be thrown immediately afterwards. Just let your constructor throw the Exception and let your application's error-handling deal with it.
Steve Dyke wrote:I was just concerned that the "new DataSource().getConnection()" was wrong. I wanted to make sure I was utilizing connection pooling and not just creating a new set of connections with each instance of the class.
It's a pleasure to see superheros taking such an interest in science. And this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|