I am pretty sure WebLogic, Websphere, Jboss EAP and other J2EE application server provides their own service to optimize database connection pooling. At this point is there any benefit to still integrate a Spring application with HikariCp? May be HikariCp performs better (in question) but there will be unavoidable issues for configuration and compatibility.
Better question is: what are the benefits to use HikariCp in a Spring application if it will deploy on major commercial application servers other than Tomcat etc..
There is an opinion that HikariCp is the fastest connection pool in java world, this graphics prove this fact. In this case criteria is statement Cycle in ops/ms. HikariCp is faster in two times than the closest rival. It's a source code of this benchmarks, if i were you, i would launch them on own PC with specific to my environment. Last link saves your time, you have already written benchmarks (it's benefits of open source). HTH
Related
What are the tools and approaches you suggest to use for monitoring performance? My app is running on Tomcat, Spring 3, JPA, Hibernate and solr. I've noticed some lag/slow activity on a certain page.
The app does not have any code of cache setup. Or even connection pooling.
Pardon my beginner-style questions, I'm only entering the "performance monitoring" world just now...
I know couple of things to look at is- dabatase calls, connection pooling, indexed tables, caching etc.
You absolutely need connection pooling. It's a no-brainer, there are libraries like Bone CP, Commons DBCP or c3p0 that do this transparently.
You must implemented automated load/stress test. JMeter is pretty easy to use, other tools like that are Gatling and Grinder.
Enable SQL logging and statistics. Most likely too many or too complex queries are slowing down your page.
Use a profiler. Either commercial (JProfiler, YourKit) or the one included in JVisualVM.
You can use this application to monitor your application:
http://newrelic.com/
He has a free plan!
We are developing a open source trading platform based on Springframework and Hibernate http://code.google.com/p/algo-trader/ and http://www.algotrader.ch. The application consists of a trading framework and several strategies that can be started independently. So far, these different parts have been running in separate JVM's communicating through RMI and JMS.
To avoid unnecessary serialization and network overhead we would like to run the entire application within some sort of container (potentially an application server). We do however have the requirement, that the individual parts of the application can be deployed, started and stopped independently.
We have looked into OSGi, but a lot of the libraries that we use are not OSGi ready yet, so this is not currently an option. Also please note, there is no web-GUI in our application.
Any suggestions on this?
Thanks
Andy
If OSGI is not an option then functionality can be broken into smaller units and then deploy them as utility jar, if deployed as utility jar they can be managed independently.
For application server I feel either glassfish or Jboss will be a good option considering they are open source and free.
Though at a later point in time you can check with Weblogic (Dev free).
So in your case you would like to break the static data configuration(Counterparty, Currencies), Dealing(Pricing, Quoting, Booking) as two separate feature.
For your choose of an application server i advise you Jboss and specially in his version 7.1 which is faster and more stable!
I am currently working on an enterprise application that is deployed to GlassFish. I am attempting to figure out the right way to communicate to a cassandra backend from within an EJB that has been deployed to GlassFish 3.1. I would prefere to use Pelops to talk to Cassandra.
Disclaimer: I am new to Java EE and the concepts behind enterprise app servers and EJBs; one of the purposes of this project is to learn these topics. This is out of scope of this question as I am really just looking to be pointed in the right direction for best practices or where I should go to find best practices; so far google has not been very helpful/consistent on this topic.
More specifically, should I be thinking about writing a JCA connector for cassandra? Using a singleton EJB that talks to cassandra via Pelops? Just use pelops directly in my EJBs? (though I thought your not supposed to create socket connections in ejbs) Something else entirely?
The EJB spec prohibits EJBs from opening server sockets, but not sockets. However, it does also prohibit EJBs from creating threads. Does Pelops (or Hector) create threads to handle its pooling?
The letter of the law aside, since both those libraries do pooling, they definitely feel like something that belongs in the resource adapter layer to me. I would be nervous about EJBs, whose lifecycle is controlled by the container, and is potentially quite short, hanging on to a resource like a connection pool whose lifecycle is somewhat independent, and should be longer.
That said, most implementations of EJB are quite forgiving, so whether the use of Pelops/Hector directly from EJBs is architecturally right or not, it is very likely that it will work.
If i had all the time in the world, i would write a resource adapter wrapping one or the other of those libraries. However, that would be a considerable investment of resources in pursuit of a negligible practical return.
we are developing a similar application where I work now, even if we do not implement EJB, we deploy a backend to Glassfish 3.1 and internally we have created a small library that talks to Cassandra.
Right now the most used library for connecting and working with Cassandra is Hector:
https://github.com/rantav/hector
It is very actively developed. I have never seen it in use inside an EJB, but I used it and it is very solid. Do not how Pelops is developed though.
What we have developed here is a very custom application tailored to our needs, that is why we didn't use Hector in the first place.
As long as you use client sockets in EJB, you should be safe, the restriction on EJB is for server socket that should be handled by the app server. But if you have other needs, you should write your JCA.
Which JDBC connection pool library should I use for a new application project (not web application)?
Apache DBCP has enough unresolved issues which are pushed until 2.0 I think.
C3P0 development seems to be stopped.
And both of them looks relatively slow.
Proxool is dead.
DBPool has almost no community (at least I've found no public one - no forums, no mailing lists...)
Apache Tomcat Pool looks to be unusable without Tomcat
I've found SQL Datasources article at Oracle website, but it seems, that it can be applied only to applets running in containers like servlets and web services.
Should I choose BoneCP may be? I don't have any huge requirements. I just need a good and easy to use database connection pool, that is in active development. Library, whose author can respond to bug reports, answer some specific question etc.
BTW, actually, I'm using MySQL only. I've found, that MySQL driver supports DriverManager interface, but I'm unsure if it actually pools connections or not.
You've done good research. I'd say, go ahead with BoneCP. Some years ago I would have suggested c3p0, but it has currently some open and unresolved issues as well. Too bad, actually. The BoneCP author is by the way also active here at SO.
It is possible use Tomcat Connection Pool without Tomcat, it is just a couple of .jars that you can include to any software. I have successfully used Tomcat Connection Pool with Resin and Jetty application servers.
Another alternative is Vibur DBCP. This is a new, concurrent JDBC connection pool based on Java dynamic proxies. It is fast, has concise source code, supports fairness parameter, JDBC Statement caching, long running SQL queries logging, and many other features.
Vibur DBCP is available in the central Maven repo, the website shows the needed Maven dependency, various configuration examples (with Spring, Hibernate 3.x/4.x/5.x), and all configuration options.
Vibur DBCP requires Java 1.7.
Disclaimer: I'm the author of Vibur DBCP.
I know its too late for answer but I just found an interesting link which has given a broader scope to answer most your queries. But at the end HikariCP and BoneCP are much better than other options.
I've been reading/learning more about Spring lately, and how one would use Spring in combination with other open-source tools like Tomcat and Hibernate. I'm evaluating whether or not Spring MVC could be a possible replacement technology for the project I work on, which uses WebLogic and a LOT of custom-rolled Java EE code. The thing is, I've always suspected that our solution is over-engineered and WAY more complex than it needs to be. Amazingly, it's 2009, and yet, we're writing our own transaction-handling and thread-pooling classes. And it's not like we're Amazon, eBay, or Google, if you know what I mean. Thus, I'm investigating a "simpler is better" option.
So here's my question: I'd like to hear opinions on how you make the decision that a full-blown Java EE application server is necessary, or not. How do you "measure" the size/load/demand on a Java EE app? Number of concurrent users? Total daily transactions? How "heavy" does an app need to get before you throw up your hands in surrender and say, "OK, Tomcat just isn't cutting it, we need JBoss/WebLogic/WebSphere"?
I don't think that the decision to use a full-fledged Java EE server or not should be based on number of users or transactions. Rather it should be based on whether you need the functionality.
In my current project we're actually moving away from JBoss to vanilla Tomcat because we realized we weren't using any of the Java EE functionality beyond basic servlets anyway. We are, however, using Spring. Between Spring's basic object management, transaction handling and JDBC capabilities, we aren't seeing a compelling need for EJB. We currently use Struts 2 rather than Spring's MVC, but I've heard great things about that. At any rate, Spring integrates well with a number of Java web frameworks.
Spring does not attempt to replace certain advanced parts of the JavaEE spec, such as JMS and JTA. Instead, it builds on those, making them consistent with the "Spring way", and generally making them easier to use.
If your application requires the power of the likes of JMS and JTA, then you can easily use them via Spring. Not a problem with that.
Google open sources a lot of their code. If you're writing low-level things yourself, instead of implementing code that's already written, you're often overthinking the problem.
Back to the actual question, Walmart.com, etrade.com, The Weather Channel and quite a few others just use Tomcat. Marketing and sales guys from IBM would have you believe different, perhaps, but there's no upper limit on Tomcat.
Except for EJB, I'm not sure what Tomcat is missing, and I'm not a fan of EJB.
What tomcat does not offer apart from the more exotic elements of Java EE is session beans (aka EJBs). Session beans allow you to isolate your processing efficiently. So you could have one box for the front end, another for the session beans (business logic) and another for the database.
You would want to do this for at least 2 reasons:
Performance; You're finding that one box to handle everything is loading the box too much. Separating the different layers onto different boxes would allow you to scale out. Session beans are also able to load balance at a more fine grained level. Tomcat and other web services of that ilk don't have clustering out of the box.
Flexibility; Now that you've moved your business logic into its own environment you could develop an alternate front end which used the same layer, but say, was a thick client front end for example. Or maybe other contexts would like to make use of the session beans.
Though I should probably point out that if you use web services to communicate with that middle tier, it could also be on tomcat!
The only reason to use a full blown Java EE server is if you need distributed XA transactions, if you don't need XA transactions then you can use Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java Mail.
Also a Java EE server is supposed to implement JMS but it does not make sense to run the JMS server in the same VM as the rest of the app server so if you need JMS you should have a separate JMS server.
I strongly disagree with all answers given here.
Everything can be added to Tomcat, including EJB, CDI, JTA, Bean Validation, JAX-RS, etc.
The question is: do you want this? Do you want to assemble all those dependencies in the right versions and test that it all works together, when others have already done this?
Let's be clear: nobody uses only Tomcat! Everyone always adds a web framework, an ioc container, an orm, a transaction manager, web services, etc etc
Lightweight Java EE servers like TomEE already include all of that and makes the full stack experience of having all those things integrated so much better.
Maybe this can be of interest:
http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html
HTH