I have never connected to a database in java before. May I know if I should go about accessing a derby database with servlet?
I have checked this: How do I access a database from my servlet or JSP?
But I saw comments on the article saying that this is a bad way to connect. Could any one explain or show me the best way to that I should code to access my derby database?
Thank you very much.
They are all right indeed, in suggesting that. We don't don't access database directly from Servlets or JSPs, these both are meant to be web tier, isn't it?
So, what to do? Grab a JDBC tutorial. The official one is an excellent choice here. That will give you a good idea about connecting to database from Java, and grasp over JDBC API. After that you should go and read about DAO pattern, and how we employ that in real apps.
Moreover, I think you also should read about MVC pattern, because it seems to me that you are not very clear on that as well.
Once you understand all these and come up with a toy like application using all these stuff. Next step would be to have a look into Connection Pooling mechanism.
Since you are using servelt you must be using a container line Apache Tomcat. You should look to define a connection pool like this http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html. If you are using any other container then that will also have similar setup.
Other option is to create a separate DBManager kind of class which looks after initializing and returning connection. This class you can use in the servlet.
Using JDBC and having your app server's application pool is a good start. You can also use some API to make your life easier like Hibernate.
It is a "bad way", because it doesn't make use of a (JNDI-managed) connection pool to obtain connections. Although acquiring a connection costs "only" a few hundred milliseconds, this has impact in a busy multiuser environment. A connection pool will worry about opening and closing connections and release them immediately on every getConnection() call so that it effectively costs almost zero milliseconds. If you sum that up in a busy multiuser environment, then the differences are noticeable.
A connection pool is usually to be configured in flavor of a JNDI datasource which is managed by the servletcontainer in question. As you didn't mention which one you're using, I can at highest point to one of my answers which contains a Tomcat 6.0 targeted example: here.
Hope this helps.
Related
I am writing a RESTful service which consumes application/octet-stream and accepts binary files to write them to disk (Tomcat 8, Windows Server 2012R2, JAX-RS). I then need to insert the file contents into an Oracle table.
The service itself runs fine, accepts files and writes them to disk.
My problem (or call it best-practice question) is, how to transfer the data to the Oracle DB. Of course I can open a connection in the service itsef which gets called everytime the service accepts a file, but is this really the "correct" way? We're talking about MANY small files (let's say 100 per minute, each about 300 byte in size).
Should I create a connection pool? Or even a standalone program which keeps the Oracle connection open permanently? Unfortunately, I can't really benchmark at the moment because I am on an isolated test server.
So, tl;dr: How to transfer the content of many small files accepted by a RESTful service to an Oracle DB?
As you are deploying on Tomcat, using the Tomcat managed connection pool is the most generic way. We use this and get very good performance out of it. You could roll your own and benchmark it, but I am not sure about the merits of this. I know I would try the way that's best integrated with Tomcat first and only if it does not perform move to libs like C3P0.
Depending on your use-case you could do without writing the files to disk and instead just insert them into the DB. Since your files are small, there would not even be a reason to go async or fork threads for insertion.
Connection pools are the most generic way to go here. There's lots of reasons - separating the concerns of connection management from connection use, scalability control through configuration, overcoming the latency associated with connection setup,...
There's lots of implementations of simple connection pools out there, they can be found in application servers or libraries - c3p0 is a nice and easy one for a standalone, self-contained webapp.
I created one api using jsp and hibernate. I used this option of hibernate -
<property name="hibernate.connection.pool_size">50</property>
What I want is If I am getting 1000 hit concurrently on api then it should use only 50 connection not more than that. I thought above option of hibernate will help me to achieve this. But I tested my api on 10000 hit and I checked the open connection. It was around 3000. It means pool of connection not working.
How to get this ?
From the Hibernate documentation:
Hibernate's own connection pooling algorithm is, however, quite
rudimentary. It is intended to help you get started and is not
intended for use in a production system, or even for performance
testing. You should use a third party pool for best performance and
stability. Just replace the hibernate.connection.pool_size property
with connection pool specific settings. This will turn off Hibernate's
internal pool. For example, you might like to use c3p0.
Like mentioned, c3p0 is a good option.
I am fairly new to using Spring JDBC and I am going to retrieve objects from the database now which have associations to other objects (one-to-many, one-to-one...). I wonder what is the proper way of doing it? I have read this answer Spring Framework JDBC DAO with agrgegation/composition which basically recommends using a ORM framework which I won't cause of performance and I find Spring JDBC quite pleasant to work with.
The original poster of the question showed an example of using one repository/dao method inside another dao/repository class. That would have been my guess of doing it too, but from what I understand you then use two different connections, and it could increase if you have other repositories as well. Is this bad even though using connection pooling provided by Glassfish?
I am not sure if I understand the answer given to the question either, nor if this is the proper way of doing it?
Spring JDBC always used the same connection in the scope of a transaction, so you should not worry about the number of connections, you only need to ensure that the load of the object occurs within a single transaction.
see DataSourceUtils.doGetConnection() if you are interested on how connections are retrieved from data source.
We have an old and big Java EE project, where at some places due to bad coding database connections has not been closed properly/or not cleaned up in catch/finally block.
We have limited our database connection pool to 100 connections. Sometimes it happens that the connection remains open and all the 100 connections are used, so the application gets hanged up. I'm trying to restructure this project, obviously I'll take care of this bad code when I get there, I'm wondering is there any lightweight Java EE framework which closes this opened db connection automatically without writing conn.close() or session.close().
Maybe something like Django where every db connection are closed at the end of every request/reposnse cycle.
I do know that I can use tools like p6spy and IronTrack SQL to look for statements that fail to close, but I'm more interested in frameworks as this project doesn't use any and I'm trying to integrate this project with a framework.
There is try-with-resource in Java 7 that may help.
Take a look
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
http://docs.oracle.com/javase/7/docs/technotes/guides/language/try-with-resources.html
Here Java 7 Automatic Resource Management JDBC (try-with-resources statement) you can similar question.
Check for detecting connection leak. I am sure, you will find some tools for this.
I think you should go through a couple different frameworks, demos should be available if you search for them and choose the one which most fits your current and near future needs. I personally like Primefaces/Hibernate (if you're in JSF).
The lightweight approach in Java EE is to use simple POJO based beans called EJBs that do the DB work.
With them, in many or all cases, the DB connection is a thing that's completely handled for you behind the covers by the server.
For instance (assuming your queries for now are native SQL):
#Stateless
public class MyBean {
#PersistenceContext
private EntityManager entityManager;
public void doDBWork() {
entityManager.createNativeQuery("update foo set a = 1").executeUpdate();
}
}
In this example when you call doDBWork a transaction automatically starts and it ends when you leave that method. Somewhere in between a connection is retrieved from the connection pool and returned to it. The code is automatically totally safe in the face of exceptions or concurrent access.
I've a connection pool to access a MySQL DB from a servlet. I get the data source using a JNDI, which is defined on my META-INF/context.xml file.
Everything is working fine, but I have to place the MySQL driver JAR within Tomcat's /common/lib folder, instead of webapp's WEB-INF/lib; otherwise the JNDI will not work (ClassNotFoundException: com.mysql.jdbc.Driver).
Is there any other way to get the datasource, which allows me to place the JAR inside WEB-INF/lib? All the examples I've found over the Internet are using JNDI...
(It's a quite simple application, I'd really prefer not to have to import 53 JARs of some framework in order to solve my problem :)
Thanks!
While most of these replies are about pools, I don't think that's your question?
I think the most direct answer to your question is, simply import and use the DataSource implementation provided by your driver. You're using MySQL Connector/J? then it's MysqlDataSource.
There are methods on it to set username, password, etc.
If you don't need it in JNDI, then you don't have to configure it in JNDI via Tomcat. You can keep the driver jar in WEB-INF/lib, sure. If you want pooling around that DataSource, indeed, just use Commons DBCP and Pool.
Here's an example of making your own pooling DataSource out of a given DataSource.
You might try what sun already suggests:
Connection Pooling
If you don't want to use JNDI, then you can't use Tomcat's connection pool mechanism, you'll need to incorporate one into your application, and that means adding 3rd-party libraries to your WAR file. It's one or the other, the choice is yours.
If you decide to go the 3rd-party route, I suggest using Apache Commons DBCP (which in turn requires Apache Commons Pool).
Simple apps grow. Frameworks may initially seem like overkill, but all too easily you gradually find that you are reinventing wheels and growing your own framework.
Consider the person who comes after you ... they go to the internet and look up a technique, find it commonly used, come back to your code and lo! you did it a different way.
The Java EE framework code, the JDBC drivers, everything should be in your server environment, no need to include it into your app. So the overhead should be quite small. This approach really pays off as you develop more applications.
Bite the bullet, save the creativity for the unsolved problems.
I definitely agree with you that datasource should stay out of context.xml. You will have to do this if you want externalize your configuration. We went through this process not long ago. It's quite easy. I can't give you the code but I can point you to the right direction,
You need to define <Resource> in your own configuration and find a way to parse it. You can use JAXP, Apache Digester. I am lazy so I use Apache Commons Configuration.
The <Resource> is just name-value pairs. You need to convert them into Properties.
You can make a datasource like this,
DataSource ds = org.apache.commons.dbcp.BasicDataSourceFactory.createDataSource(prop);
A side-effect of doing this is that you can disable JNDI (useNaming="false") to make server a little bit lighter.