I am building a small website for fun/learning using a fairly standard Web/Service/Data Access layered design.
For the Data Access Layer, what is the best way to handle creating Connection objects to call my SQL stored procedures and why? Bearing in mind I am writing a lot of the code by hand (I know I could be using Hibernate etc to do a lot of this for me)...
1) Should I create one static instance of the Connection and run all my querys through it or will this cause concurrency problems?
2) Should I create a Connection instance per database call and accept the performance overhead? (I will look into connection pooling at a later date if this is the case)
You should use one Connection per thread. Don't share connections across threads.
Consider using Apache DBCP. This is a free and standard way of configuring database connections and drawing them from a pool. It's the method used by high-performance web servers like Tomcat.
Furthermore, if you're using DBCP, since it's a pool (read: cached), there's little penalty to creating/closing connections frequently.
The standard way is to set up a DataSource. All application servers are able to do so via their admin console. The pool is then accessible by it's JNDI name (e.g. "jdbc/MyDB").
The data source should, in fact, be a connection pool (and usually is). It caches connections, tests them before passing to the application and does a lot of other important functions.
In your code you:
resolve JNDI name and cast it into DataSource
get a connection from the data source
do your work
close the connection (it goes back to the pool here)
You can set up the pool yourself (using any of freely available pool implementation), but it really doesn't make any sense if you're using an application server.
P.S.
Since it's a web application a good way to make sure you have closed your connection after the request is to use HttpFilter. You can set up one in web.xml. When the request comes, acquire the connection, put it into ThreadLocal. During the request, get the connection from ThreadLocal, but never close it. After the request, in the filter, close the connection.
Related
I'm looking at using PooledConnectionFactory in a Tomcat application, where in a Tomcat POST handler I want to drop a message into a queue to be picked up by a single remote consumer. AMQ pools both Connection and Session objects, and I'm trying to understand when I should use one over the other.
The approach I'm considering is to have a single Connection and set MaximumActiveSessionPerConnection to match my Tomcat threads, and the POST handler would borrow and return Sessions from the connection. Does this sound reasonable, or are there are advantages to pooling Connections instead?
If it matters, I'm not using Spring or other web app frameworks, just Tomcat. I'm persisting messages to disk in AMQ.
Both approaches should be functionally equivalent, and the difference in the code to do one vs. the other should be relatively small.
In terms of performance I don't think it will really matter as your bottleneck will be on the consuming side not on the producing side since you have a single consumer and potentially many concurrent producers.
Personally, I would prefer letting the pool do all the work and just writing the application as if it is creating a connection and session every time it sends a message (which would obviously be a huge anti-pattern without a pool).
What is a DataSource in java?
Can someone please explain me in simple language?
DataSource implementation classes allow you to use connection pool and loose coupling for connectivity.
Most of the times we are looking for loose coupling for connectivity so that we can switch databases easily.
Creating connections can be heavy process and it is not a good idea to let every part of program create its own connections which can lead to resource starvation and slow performance. that's why we use connection pooling. most database drivers provide datasource implementation classes that can be used in connection pool.
DataSource is an abstraction, a way to represent getting access to data from some source with some connection. It frees you to not worry about,
Having to think about how connection is established and will be maintained from many varying sources (think different databases, cloud storage resources)
Not worrying about what will happen if multiple clients request data from the same source and if those clients will get a proper connection object, or null - because the number of connections, there optimization and scheduling is a challenge on its own.
In the same respect, easier to manage connection timeout settings.
Database vendors and data providers need not worry about you learning their specific API if they can go ahead and implement the DataSource interface which describes how your service/server may connect to them, and you need not worrying about connection intricacies and so on.
Here is a good read from the official documentation itself on Oracle.
To answer your main question, I'll summarize in the below 3 points,
An interface to be implemented by a vendor
A factory pattern for connections to the actual data source
Its main functions to be implemented and of concern are just getConnection() and getConnection(String username, String password) where both return the Connection object (read).
According to documentation, the DataSouce interface is something like DriverManager. In most applications, it is connection to the database.
I'm making a web service in the form of a small forum for a college project. The web service provides a bunch of methods to access and modify a database, and then a JSP/servlet will use that web service to present the forum to users.
I have all my methods set up but I'm still not certain how to properly set up my database connection. Right now I have a Connection object in the web service class file and the connection is made in the class's constructor. I use that connection object all the way through in all my methods so they all rely on that constructor being run. I'm not certain that's correct.
Is there a better way of doing this? An instructor told me an instance of the web service gets created every time someone accesses a page, that sounds like an expensive operation to me.
EDIT: I had a look at connection pooling and everything I've found so far (including this requires additional libraries. I'm limited to stock Java SE/EE without additional libraries so that's out of the question.
This is a very bad idea. You should not have a Connection object that's shared. It can't scale like that, and it's not thread-safe.
A better approach is to use a connection pool. Get the connection when you need it, use it, and close it in the scope of the same method.
I think your friend is misinformed: a web service should stand alone, separate from any pages. It's managed by a container. It might be a singleton or a pooled object, but you don't create one for every page.
Best to post some code however from the brief explanation a couple of problems come to mind:
Your not pooling the connections which won't be very effective under any real load.
Creating connections are expensive so if you are executing the constructor quite frequently then you'll be creating a lot of connections.
Where are you closing the connection?
Make sure you guard against sql injections.
You shouldn't create the connection in the constructor since you will most likely have lots of problems with inactivity, connection state, io problems, ...
I would rather use a DataSource from the Apache libraries such as the BasicDataSource.
BasicDataSource dataSource = new BasicDataSource();
dataSource.setUrl("jdbc:...");
dataSource.setUser(...);
dataSource.setPassword(...);
And then, in each method of your web service, you invoke dataSource.getConnection() to get a connection. Internally, it uses a connection pool, as suggested in another answer.
I'm writing a traffic auditing servlet filter.
I need to query the database for every HTTP request. There is no connection pool. (I'm adding this filer to the existing application).
I created a JDBC connection object in init() method. And made synchronized methods that doing DB query. In 'doFiler()`, I call these synchronized methods 1~2 times.
Can this be big problem?
-- UPDATE --
Not a heavy loaded server.
It runs on single machine. It is serving hundreds KB media files and outgoing bandwidth is 100Mbps, so maximum simultaneous users could be at most 100, I think.
I just wondering.. what's the recommended approach for servlet filters using DB connections.
I'd suggest to use JNDI resource - you only need to register JDBC resource and later you may obtain the connection.
why you want to do this in filter? just get the connection in the servlet and release it after you done with it -- it is enough for your load, and simple enough.
Scenario:
I have been using Java SE for quite some time, working with threads etc, though I have little experience with Java EE.
I have a 3rd-party Java library that connects to a remote server (at the 3rd-party company). The library creates several threads and is keeping the connection alive by itself.
I am not allowed to open new connections over and over (by creating new instances of the library). I need to keep the same instance of the library which will keep the connection up at all time.
This is quite easy in a Java SE application.
Now, I want to create a web service (perhaps using GlassFish or similar) to use internally at my company to be able to use the functionality of this library with its connection.
In other words, I need a custom remote connection (that is not created by or managed by my code) to be kept alive between request instances.
Question:
Is this possible to achieve? If so, which technology should I take a look at?
you can do that using connection pool.when ever a connection required to remote server, get the connection from this pool instead of instantiating every time.This will help you in maintaing better memory foot print and efficiency.If connection is no longer in use, you can return the connection to pool.
I have recently implemented a similar system, using Tomcat as the Servlet Container and Metro 2.0 as the JAX-WS implementation. My service maintains socket connections to backend components (implemented in C++) and communicates with them using a proprietary network protocol.
I used a 'Component Manager' thread to manage the high-level communication with the Components (connection establishment, handshaking etc.) and a 'Network Selector' thread that managed the actual communication with the Components. This 'Network Selector' used asynchronous non-blocking sockets using the Java Socket Selector family of classes - using a single thread to interact with the Socket Selector class is an important point as some Java platforms exhibit bugs when multiple threads are used.
It's working very well so far, so I can tell you that it's certainly possible. If you require any clarification then please post here or e-mail me (see my profile).
You need to have a factory maintaining the connections, and then provide it through JNDI in the same way that e.g JDBC connection pools are provided.
You then need to ensure that the connections are returned to said factory and then integrate it in the application server life cycle so that it is pulled up and down programatically.
Note that there is a nasty classloader problem lurking here if you are not careful. You will have to have a common class to the factory and the clients and if it is not one in the standard runtime library you will need to figure out a way to have it correctly shared unless you want to use reflection to get to the methods.