Win a copy of Transfer Learning for Natural Language Processing (MEAP) this week in the Artificial Intelligence and Machine Learning forum!

Steve Dyke

Ranch Hand
+ Follow
since Nov 16, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Steve Dyke

Tim Holloway wrote:

4. NEVER save a Connection. Especially across servlet process calls. Connections are Interfaces, not Objects, and they are not guaranteed serializable. Obtain a Connection from the pool, process the database functions and return the Connection to the pool AS SOON AS POSSIBLE. This allows more efficient use of Connection resources, especially when there are many concurrent web requests.

Could I please get a little more clarification here?

In my Servlet Context Listener I use setAttribute to set up application level data.
Would this be acceptable in lieu of a connection for each constructor.

I also have instances where I use this approach if I have embedded SQL calls. I will wrap one of these Connections around all of the SQL code.

6 days ago

Tim Holloway wrote:Definitely, please explain more clearly what you are actually hoping to do.

I got it figured out. Thanks for steering me in the right direction. Here is the code I used.

1 week ago
I have a data file that contains file paths.


In java I would like to loop through this data and create this path result(pdf file) in a particular shared folder.

I will make the directory dynamically:

1 week ago
I am initializing several remote data list in my Servlet Context.

If within the app the remote data gets changed I do this:

Is the removeAttribute necessary?
Will this process cause a negative affect on other users who are currently using the app?
2 weeks ago

Tim Holloway wrote:Yes, in answer to the first question.

I thank you for spending time to explain this to me and your sense that I need a more basic explanation than should be required.

This application is huge. I have had it deployed and work on it daily to improve it for the last 14 years. It has came a long way.
However, I have always felt the way I was connecting to the data was not working the best way. Now I know thanks to JavaRanch.

I have tried to break this line down into more statements but to no avail.

1 month ago

Stephan van Hulst wrote:Your code would be a LOT simpler and robust if you used REST controllers and an IoC container. Then all you needed to do would be something like this:

This certainly looks like cleaner code. However, I have not used annotation up to this point.
I tried to use this piece of code and even with reading several documents(maybe not the correct ones) I still do not understand the @Resource or @Produces. I get errors on these.
Do they need to be defined in my app? Are they a part of a library? Are they native?
Sorry to be unlearned in this respect. But I desire to learn and make my application better.
1 month ago

Tim Holloway wrote:Allowing for my incredible ability to miss things, that looks OK to me. Main difference is that I probably would break down the connection fetch into multiple statements, since if any of the steps fails, it's hard to tell which one failed from a stack trace. But of course it's not supposed to fail.

Are you referring to this?

And just to make sure I need to use the following any where I fetch the connection fetch:

One more question. Are the Connection dc instances scoped to the request?
1 month ago

Tim Holloway wrote:Whoah. Let's keep this simple and in keeping with accepted Best Practices.

Recapping what others have said:

1. Don't create a connection pool - or Connections! - yourself within the webapp. All JEE-compliant webapp servers have the ability to create and manage Connection Pools which can be attached to single webapps or shared between multiple webapps. That insulates the database particulars from the application code, leading to easier testing (just swap out databases in the server) and more portable coding.

The connection pool is created on the WebSphere Application Server.

I have this class:

Tim Holloway wrote:2. The server will publish Connection Pools that it creates for a webapp as JNDI resources. It's a good idea to set up a ServletContextListener that locates that pool(s) via JNDI lookup and caches the pool interface as an Application-Scope object. Not that JNDI is that much overhead, but it's less trouble to pull the pool from cache. However, DO NOT CACHE CONNECTIONS! More on this later. The Pool will exist before the app starts and continue to exist until after all apps that use it shut down, so caching the pool interface is OK.

My Servlet Context Listener:

Is this correct so far?

If so in my classes that need to get remote data I would??

1 month ago

Stephan van Hulst wrote:So you are implementing a custom HttpServlet to handle requests? What do the requests look like, are they like REST requests or SOAP requests or some custom format?

Servlet Context Listener:


Client side:

Server side:

Data layer:

1 month ago

Stephan van Hulst wrote:Also, how are you handling client requests? Are you writing custom servlets? Are you using some MVC framework? Are you using enterprise beans?

My Java version is 1.7.
I am not using a formal framework but try to pattern the app using MVC.
I use JSP/jQuery on the client side. This makes requests to the servlets.
I use the sql Connection class(jt400.jar) to communicate with our AS400 data server.
I have connection pool set up on the WebSphere Application Server.
In my Deployment Descriptor there is a JNDI reference set up to the connection pool.
1 month ago

Stephan van Hulst wrote:Yeah. What you're doing is wrong. It shouldn't be up to your application to decide what database connection to use.

What web application framework are you using, and what web application container will you be running the application in?

Rational Application Development(Web)
WebSphere Application Server running on an iSeries machine.
1 month ago

Stephan van Hulst wrote:Yeah. What you're doing is wrong. It shouldn't be up to your application to decide what database connection to use.

I still have the question. Do I need to do a try-finally to close the dc on the following code?

1 month ago

Stephan van Hulst wrote:That looks like a bad idea to me. Rogue code can just change the mode from a completely unrelated part of the code and you'd be none the wiser. Why do you set the mode in the code? What is the difference between DB2WeberCustom and DB2WeberDEV?

Two different servers. Production and Test.
1 month ago

Stephan van Hulst wrote:It's good to use a connection pool. It's bad to manage the connection pool yourself.

You need to configure a DataSource in your web container or application server (e.g. Tomcat, WildFly) and you need to configure your persistence framework (e.g. Spring Data JPA, Hibernate), to use the connection pool configured in your application server. All of this can be done through config files.

What application server and persistence framework are you using? Note that instead of a high level persistence framework you can also use JDBC to access the connection pool directly.

This is what I use for connection pooling:

1 month ago

Stephan van Hulst wrote:This doesn't look right at all. Why are you opening a connection in a filter? And why are you ignoring certain URLs? And why are you wrapping the request/response in a custom wrapper?

I don't think a filter is the right place to set up connections. And even if you really want to do this, you're doing too much in a single filter. Filters should have a clear, single responsibility.

I found this in Stack Overflow:

In a Web app, each http request from a user runs in its own thread (or through a thread pool). Having a global connection object shared by all requests is not a good idea because only one thread at a time will be able to use it and it will become a bottleneck for your app.

The recommended setup is to use a connection pool (e.g. C3P0) that is initialized on server startup (either automatically through config or manually in your ServletContextListener). The connection pool will create and close the connections as needed. When you receive an http request (servlet's doPost or doGet), you then just have to get a connection from the pool and return it to the pool once you're done processing that request.

You can use a ServletFilter to automate that part. In your filter, before the call to chain.doFilter(), you get a connection from the pool and store it in a request attribute. After the call to doFilter(), you return it to the pool.
1 month ago