Hi, Yes, this is potentially a problem. It can be fixed in multiple ways (always use a new Calendar, use a ThreadLocal,...). So far it didn't show up in my tests, and so far nobody complained.
> Wouldn't it be sufficient to just call new Timestamp(time)? Well, the problem is what is the value of "time". Daylight time saving comes into play here, and and the rules are quite tricky. Actually, when writing an application, I would avoid using java.util.Time, java.sql.Date / Time / Timestamp, and try to use String instead. This avoid quite many problems. Unfortunately you may need to parse the String into year / month / day and so on. But this avoids other problems. Regards, Thomas On Monday, May 5, 2014, Lukas Eder <[email protected]> wrote: > Hello, > > I was profiling a performance issue in our own software, when I noticed an > excessive amount of time being spent > in org.h2.util.DateTimeUtils.getTimeTry(), even if the benchmark selected > only one timestamp column with dozens of other columns: > http://i.imgur.com/KJdXEWB.png > > I am a bit confused by the algorithm, and I suspect there are a couple of > issues here. The org.h2.value.ValueTimestamp type stores nanos and > dateValue, which are then converted to a JDBC java.sql.Timestamp through a > Calendar. Why? Wouldn't it be sufficient to just call new Timestamp(time)? > The TimeZone that is applied in DateTimeUtils.convertDateValueToTimestamp() > is the default one, so I don't see the benefit of passing through Calendar. > > Things get worse when looking at giveTimeTry(): > > private static long getTimeTry(boolean lenient, TimeZone tz, > int year, int month, int day, int hour, int minute, int second, > int millis) { > Calendar c; > if (tz == null) { > c = getCalendar(); > } else { > c = Calendar.getInstance(tz); > } > synchronized (c) { > c.clear(); > c.setLenient(lenient); > setCalendarFields(c, year, month, day, hour, minute, second, > millis); > return c.getTime().getTime(); > } > } > > This method (possibly) synchronizes on a global static calendar object. If > this happens in a high throughput scenario, pretty much every database > session will then need to synchronize on this single object. > > What are your thoughts on this? > > Cheers > Lukas > > PS: I was using 1.4.177 for this benchmark. > > -- > You received this message because you are subscribed to the Google Groups > "H2 Database" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > [email protected]<javascript:_e(%7B%7D,'cvml','h2-database%[email protected]');> > . > To post to this group, send email to > [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> > . > Visit this group at http://groups.google.com/group/h2-database. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
