tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@mail.more.net>
Subject java Date related classes synchronization bottlenecks
Date Thu, 10 Jul 2003 22:46:06 GMT
David Rees wrote:
> Glenn,
> 
> This is quite interesting.  How many concurrent threads need to be
> running before this bottleneck starts to become a significant issue?

The worst case we have seen so far is when a JDBC query was made which
returned 100's of result sets where one of the fields was of type
DATE, TIME, or DATESTAMP.  A java.sql.(Date|Time|Timestamp) would get
created for each row in the result as you iterated over it. This was
with the MySQL Connector/J JDBC driver, other JDBC drivers might perform
better.

It doesn't take too many conncurrent requests doing this before the app
server starts bogging down.  Especially when there are other things using
Date related classes like web application code and Loggers.

Here is an example of what happens with the org.apache.catalina.logger.FileLogger:

      public void log(String msg) {

          // Construct the timestamp we will use, if requested
          Timestamp ts = new Timestamp(System.currentTimeMillis());
          String tsString = ts.toString().substring(0, 19);
          String tsDate = tsString.substring(0, 10);

         ...
     }


Now use jar to unarchive the src.jar file in your java SDK.
Take a look at the java.sql.Timestamp.toString() method which the FileLogger
above uses.

Each of the six get methods used in Timestamp.toString() trigger one or two
synchronizationsin in the underlying java.util.Date object.  Each of those get
methods end up calling a synchronized block on a static object in java.util.Date
and a call to the  static synchronized TimeZone.getDefault() method,
or one to two calls to the static synchronized TimeZone.getDefault() method.
So when the FileLogger logs it ends up hitting a synchronized block a minimum of
six times, but usually twelve times.

To verify this look at the source for java.util.Date.getField().

And there are many other synchronization bottlenecks in the following Date
related classes:

java.util.Calendar.getInstance()
java.util.Date
java.util.TimeZone.getDefault()
java.sql.Date
java.sql.Time
java.sql.Timestamp

  > Does a simple test case which simply starts up a number of threads which
  > all use one of the classes shown below display the problem nicely?

I am sure it would, I haven't had time to write one up yet.

Regards,

Glenn



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message