Comments for Javatech http://javatech.org The Bleeding Edge of Java Technology Wed, 03 Sep 2008 17:21:16 -0400 http://wordpress.org/?v=2.8 hourly 1 Comment on ArrayList vs Vector by Darren Hicks http://javatech.org/2008/03/arraylist-vs-vector/comment-page-1/#comment-335 Darren Hicks Wed, 03 Sep 2008 17:21:16 +0000 http://javatech.org/2008/03/18/arraylist-vs-vector/#comment-335 It would appear, that for java6 on windows xp: ArrayList.add() is 13% faster than Vector.add() ArrayList.contains() is 3% faster than Vector.contains() It would appear, that for java6 on windows xp:

ArrayList.add() is 13% faster than Vector.add()

ArrayList.contains() is 3% faster than Vector.contains()

]]> Comment on C3P0 vs DBCP – The Straight Dope by raman http://javatech.org/2007/11/c3p0-vs-dbcp-the-straight-dope/comment-page-1/#comment-45 raman Sun, 24 Aug 2008 20:21:12 +0000 http://javatech.org/?p=17#comment-45 I am going to stick with DBCP, which is tested and tried. Why not just have a version of DBCP that supports multi-threaded apps. Why do we need anther version? C3P0 has given me enough headaches. I am going to stick with DBCP, which is tested and tried. Why not just have a version of DBCP that supports multi-threaded apps. Why do we need anther version?
C3P0 has given me enough headaches.

]]> Comment on Connection Pool Showdown by Anonymous http://javatech.org/2008/02/connection-pool-showdown/comment-page-1/#comment-272 Anonymous Wed, 20 Aug 2008 14:58:09 +0000 http://javatech.org/?p=29#comment-272 Nice work. A couple of questions. I'm confused by "...and confirmed that DBCP is the fastest pool in the West, so long as there isn’t any complicated synchronization being done by the code using DBCP!" You mean that DBCP is fastest if the code calling DBCP doesn't use complicated synchronisation? If the code calling DBCP has performance problems, then of course DBCP can't help. Wouldn't the same be true for c3p0 and Proxool? Will you publish your test case for review? What version of each package did you use? thanks, matt Nice work. A couple of questions.

I’m confused by “…and confirmed that DBCP is the fastest pool in the West, so long as there isn’t any complicated synchronization being done by the code using DBCP!” You mean that DBCP is fastest if the code calling DBCP doesn’t use complicated synchronisation? If the code calling DBCP has performance problems, then of course DBCP can’t help. Wouldn’t the same be true for c3p0 and Proxool?

Will you publish your test case for review?

What version of each package did you use?

thanks,
matt

]]> Comment on Collections Performance Benchmarks by anon http://javatech.org/2008/03/collections-performance-benchmarks/comment-page-1/#comment-339 anon Mon, 18 Aug 2008 18:37:51 +0000 http://javatech.org/2008/03/25/collections-performance-benchmarks/#comment-339 Was there a followup to this, or is Vector really faster than the ArrayList? Was there a followup to this, or is Vector really faster than the ArrayList?

]]> Comment on Connection Pool Showdown by Darren Hicks http://javatech.org/2008/02/connection-pool-showdown/comment-page-1/#comment-271 Darren Hicks Sat, 21 Jun 2008 04:34:45 +0000 http://javatech.org/?p=29#comment-271 Well, I guess it doesn't really have to be all that complicated to create an issue with DBCP. The thing is that DBCP's methods for acquiring and returning connections to the pool are synchronized which make it possible for deadlocks to occur amongst client threads. With C3P0, this synchronization isn't present ( on the returns, at least ) and therefore the deadlocks don't happen. C3P0 has a separate pool of helper threads which are responsible for getting the threads back into the pool without synchronization. Well, I guess it doesn’t really have to be all that complicated to create an issue with DBCP. The thing is that DBCP’s methods for acquiring and returning connections to the pool are synchronized which make it possible for deadlocks to occur amongst client threads. With C3P0, this synchronization isn’t present ( on the returns, at least ) and therefore the deadlocks don’t happen. C3P0 has a separate pool of helper threads which are responsible for getting the threads back into the pool without synchronization.

]]> Comment on Connection Pool Showdown by jer http://javatech.org/2008/02/connection-pool-showdown/comment-page-1/#comment-270 jer Wed, 18 Jun 2008 23:22:55 +0000 http://javatech.org/?p=29#comment-270 Can you explain what you mean by "complicated synchronization?" What in particular is it I need to watch out for and why? Can you explain what you mean by “complicated synchronization?” What in particular is it I need to watch out for and why?

]]> Comment on Spring Dynamic Modules for OSGi by Mike Francis http://javatech.org/2008/06/spring-dynamic-modules-for-osgi/comment-page-1/#comment-342 Mike Francis Tue, 17 Jun 2008 07:13:16 +0000 http://javatech.org/2008/06/17/spring-dynamic-modules-for-osgi/#comment-342 I saw your summary of Adrian Colyers presentation on InfoQ and thought I would answer at least one of your questions - Paremus - who are they? We offer a model-driven, distributed, scalable, resilient, OSGi runtime called Infiniflow. Infiniflow offers transparent support for Spring DM, allowing you to add scale and resileince to your Spring applications without any need to change the code, all that is required is a simple config change. You can find out more details at ww.paremus.com. We have also made the foundations of Infiniflow available as the open source Newton project (www.codecauldron.org). I saw your summary of Adrian Colyers presentation on InfoQ and thought I would answer at least one of your questions – Paremus – who are they?

We offer a model-driven, distributed, scalable, resilient, OSGi runtime called Infiniflow. Infiniflow offers transparent support for Spring DM, allowing you to add scale and resileince to your Spring applications without any need to change the code, all that is required is a simple config change. You can find out more details at ww.paremus.com.

We have also made the foundations of Infiniflow available as the open source Newton project (www.codecauldron.org).

]]> Comment on C3P0 vs DBCP – The Straight Dope by mike http://javatech.org/2007/11/c3p0-vs-dbcp-the-straight-dope/comment-page-1/#comment-35 mike Wed, 09 Apr 2008 20:21:43 +0000 http://javatech.org/?p=17#comment-35 Thanks for taking the time to benchmark and share with everyone... I haven't used Proxool at all but was recently using DBCP on a busy tomcat site (15M hits/day) and was running into a wall of contention that turned out to be DBCP... Switched to C3P0 and this issue was immediately resolved and actually looked like it was doing so with less connections and faster response times. Thanks for taking the time to benchmark and share with everyone…

I haven’t used Proxool at all but was recently using DBCP on a busy tomcat site (15M hits/day) and was running into a wall of contention that turned out to be DBCP… Switched to C3P0 and this issue was immediately resolved and actually looked like it was doing so with less connections and faster response times.

]]> Comment on C3P0 vs DBCP – The Straight Dope by andy http://javatech.org/2007/11/c3p0-vs-dbcp-the-straight-dope/comment-page-1/#comment-34 andy Sun, 25 Nov 2007 06:15:36 +0000 http://javatech.org/?p=17#comment-34 how about adding Proxool to the comparison ? how about adding Proxool to the comparison ?

]]> Comment on C3P0 vs DBCP – The Straight Dope by Darren Hicks http://javatech.org/2007/11/c3p0-vs-dbcp-the-straight-dope/comment-page-1/#comment-33 Darren Hicks Fri, 23 Nov 2007 23:59:24 +0000 http://javatech.org/?p=17#comment-33 The biggest thing is the lack of blocking in multithreaded environments. With DBCP, even the act of returning a connection to the pool is a blocking operation. In production environments where there are other resources being worked with ( possibly also synchronously ), there then arises the likelihood of slowdowns and the potential for deadlocks. It only takes a few of these occurences to see the value C3P0 adds. Additionally, C3P0 ships with JMX management and can be fine tuned to a greater extent than DBCP. I've got to finish the article and come up with the test cases demonstrating the DBCP slowdowns and deadlocks when using other synchronous resources ;) The biggest thing is the lack of blocking in multithreaded environments. With DBCP, even the act of returning a connection to the pool is a blocking operation. In production environments where there are other resources being worked with ( possibly also synchronously ), there then arises the likelihood of slowdowns and the potential for deadlocks. It only takes a few of these occurences to see the value C3P0 adds. Additionally, C3P0 ships with JMX management and can be fine tuned to a greater extent than DBCP.

I’ve got to finish the article and come up with the test cases demonstrating the DBCP slowdowns and deadlocks when using other synchronous resources ;)

]]>