Hello Gene! Just a lurker at this list, but what you've pointer out is very impressive! :-(
How can this be fixed? One may be bloody enough to write his own utility class all like java.util.Date but with its own staticCal being not static. Will it actually waste much memory? Another solution would be to use some kind of pool for these calendars, but this will require synchroniztion. Thoughts? BTW: if you're running on Sun's jvm you did not have to jad: in their jdk distribution there's src.zip or src.jar that has most of the sources :) GC> Please bear with me, this may not seem like a ejb/j2ee question GC> at first, but is very relevent to application container development. GC> We are doing thread dump performance analyses of our production GC> application servers and find the majority of our threads (say, 40 GC> out of 50) are in wait states, waiting on the constructor or an GC> accessor (getYear, getMonth, etc..) of java.util.Date. GC> After jad'ing the class, I discover all these methods and constructors GC> are synchronized on a static member variable, Calendar staticCal. GC> I am sure a lot of people use java.util.Date as a field in their data GC> beans, or invoke JDBC ResultSet.getTimestamp() which eventually constructs GC> a java.util.Date, and have seen this problem before, where in a multi-threaded GC> environment the majority of their threads are blocked on Date. GC> Is there a way around it, short of spinning our own Date class? Thanks. GC> Gene - Anton [EMAIL PROTECTED] [EMAIL PROTECTED] =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
