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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
