I am responsible for maintaining a bunch of legacy code which involves several deployed servlets; some through Tomcat 5.5 (yes I know - I did say legacy code!) and others through Glassfish 3.3. All connect using the ojdbc14 driver, to Oracle 10 databases. All use pooled connections.
However, occasionally, the connection to the DB is dropped, the DB restarts, etc., and the servlets fail until someone notices and they are re-deployed. Not. Cool. I understand there is some way to monitor the DB connection the servlet makes, so that, in the event of a lost connection, the servlet 'knows' - how do I accomplish this? And, can I make the servlet smart enough to recover itself by reinstigating the DB conection? I've searched around for an answer, but I have not been successful. Suggestions and pointers muchly appreciated.. I'm a bit of a newbie at this. Thanks!
Related
I am trying to understand the correlation between Database connections and spring boot app. My spring boot app is connecting to one schema and I am running 4 such spring boot apps on my system. Each app is connecting to a different schema.
The problem is that these 4 apps are acquiring 50 oracle db connections, but when I close all apps and open DB through oracle sql developer only one connection is acquired.
I don't have enough rep to post this as a comment.
By default Spring Boot uses HikariCP as a connection pooling framework. Some good information can be found at Baeldung, which I recommend using as it covers lots Spring Boot functionality and is almost always up to date.
https://www.baeldung.com/hikaricp
Spring-boot specific information:
https://www.baeldung.com/spring-boot-hikari
While 10 connections are not at all required, you can 'play' around with how much is best (or most optimum) for your app and set it as best fits your design. Usually this will be done by optimizing this as the need arises in your application. 10 is what spring/hikari identifies as a good starting point for most projects.
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#data.sql.datasource.connection-pool
Since I had to post this as an answer I'll go a little more in depth in your actual question:
If we think of a connection to a database without a pool we can think of:
The application requests the driver to open a connection to your database
A socket is opened between your application and the database
You are authenticated to the database
Your query runs and the connection is closed
This is fine in a small application without many requests going through, but hopefully you can see the issue here as we scale and get more users. Removing the first 3 steps can make a huge difference.
It should also be noted that while your database holds 3 connections, the connections will be idle and not generating much (if any) load on your database.
I have a java web application that needs to control multiple MySQL databases (same schema) at the same time.
I’m using Tomcat as a web container and hibernate. Connecting up to 3 databases works fine for both reading and writing to the databases.
As soon as I attach the 4th database and write to this database the connection gets lost. I think that this is because of some limitation somewhere but I don’t have the slightest idea what and where.
I would appreciate any help on this.
I'm a Java EE developer and we typically use Weblogic to deploy our apps. Now I'm faced with a new desktop application which requires logging, database connectivity and mail.
After some investigation I'm realizing that desktop apps are a completely new world to me and I'm not sure if I'm choosing the right libraries to support my app.
These are my questions:
In our Weblogic projects we used Log4j and I want to use it again in my desktop app. Is it a bad idea? Should I use a better logging framework?
In Weblogic we retrieve database connections with JNDI but now it seems impossible to do the same. How do I perform the same action in a desktop application so I can connect with a remote database? Is the combination c3p0 + database driver a good approach for this?
Is there any framework/JAR which provides all this stuff (log + ddbb + mail) as an integrated solution? Workmates told me Spring could help. I also found Warework.
In our Weblogic projects we used Log4j and I want to use it again in
my desktop app. Is it a bad idea? Should I use a better logging
framework?
No, it is not a bad idea and perfectly works. Personally, I'd go with java.util.logging as it does the job fairly well and it reduces your applications' footprint (storage). Although, it's configuration is a bit tricky.
In Weblogic we retrieve database connections with JNDI but now it
seems impossible to do the same. How do I perform the same action in a
desktop application so I can connect with a remote database? Is the
combination c3p0 + database driver a good approach for this?
You can directly connect to your database using pure java.sql JDBC API (tons of examples available in the internet), but always have to distribute the proprietary database drivers as part of your application (mySQL, Oracle, DB2, etc.). Furthermore it's possible to directly use connection pools provided with those drivers by using their proprietary APIs (fairly easy to encapsulate). Nevertheless, there are a number of issues:
latency; database protocols are fairly sensitive when it comes to latency (distance between client and database server). Having a database in the UK and desktop clients in US is probably not a good idea.
security 1; you have to distribute database user credentials to each and every desktop client. Be aware of that.
security 2; your database security requirements may demand for transport security (packet encryption).
change management; applying non-backward compatible updates to your database requires you to update all desktop clients (believe me - it's not fun).
network; depending on your environment, certain ports and/or protocols may be blocked.
Is there any framework/JAR which provides all this stuff (log + ddbb +
mail) as an integrated solution? Workmates told me Spring could help.
I also found Warework.
Logging and database access are not an issue and work fairly well without any third-party framework. Of course, those frameworks might provide value regarding other aspects (abstraction, DI, JDBC abstraction, etc.), but this is a topic of detailed software design. Sending emails directly from a desktop application might become an issue, regardless of the framework in use. Just some things to keep in mind:
which SMTP relay server do you want to use?
in case of an enterprise environment, your IT operations teams might not allow you to use their SMTP server from each desktop (keep spam in mind).
Conclusion: In desktop scenarios an application server is not a bad idea either. You should have your desktop application to communicate with an application server only by using e.g. JSON, XML, SOAP over HTTP/HTTPS or RMI, etc. The application should be responsible for the complex tasks like database access, transaction management, fine grained security, email, etc.
The title pretty much says it all, but here's some background.
We have a database configured in glassfish accessed by a website deployed on glassfish, we also access the database from an external java application, it occurred to me that this could be somewhat inefficient since we open quite a few connections to the database from our external app. So I was wondering if we could somehow access he database through glassfish's connection pool?
Thanks in advance.
Piers
You'll have to try this.
http://javahowto.blogspot.com/2006/08/access-glassfish-datasource-remotely.html suggests it is possible to look up the connection pool via JNDI from a standalone client. An actual client code example is given at http://javahowto.blogspot.com/2006/08/access-jboss-datasource-remotely-from.html#client
That would only be possible if your external application was running in the same VM as glassfish. The word "external" says: Nope, not possible.
Note that databases are designed to handle lots of connections. That's one of the main reasons why they exist: To allow several programs at once to work on the same data.
I don't think you can access the pool, if your program does not run on glassfish.
A few connections to the database shouldn't matter too much, at least if the aren't created and destroyed very often. You could build a pool in your external application as well, if that is the case.
Well I'm answering my own question, and it's not a brilliant answer but it does sort of fulfil the requirements of my question.
What you can do is connect to an EJB from an external java application, if the bean provides access to your database then by using it you will be making use of the connection pooling provided by glassfish.
You can find info on how to do this
here - https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
In terms of efficiency I'm not sure if this is a good idea since it may put excess strain on your web application, in my initial idea I was thinking to bypass the webapp completely and communicate directly with glassfish, any comments on this would be appreciated.
Another option is to add a web service to your Glassfish data access object.
You could then access the database with SOAP or REST calls.
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.