[DERBY-4633] Cache default calendar in result sets and statements on client driver

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Not A Problem
• Affects Version/s: 10.6.1.0
• Component/s: JDBC, Network Client
• Labels: derby_triage10_9
• Urgency: Normal
• Issue & fix info: Newcomer
• Bug behavior facts: Performance
• Assignee: Jayaram Subramanian
• Reporter: Knut Anders Hatlen
• Created: 27/Apr/10 17:13
• Updated: 24/Jul/12 17:28
• Resolved: 08/May/12 12:25

Description

After the changes in DERBY-4582, these methods now allocate a default calendar object on each invocation (on the client driver), whereas they didn't before the fix:

ResultSet.getDate(int)
ResultSet.getTime(int)
ResultSet.getTimestamp(int)

PreparedStatement.setDate(int, java.sql.Date)
PreparedStatement.setTime(int, java.sql.Time)
PreparedStatement.setTimestamp(int, java.sql.Timestamp)

CallableStatement.getDate(int)
CallableStatement.getTime(int)
CallableStatement.getTimestamp(int)

The embedded driver prevents excessive allocation of default calendar objects in these methods by caching an instance in ConnectionChild (the super-class of EmbedResultSet, EmbedPreparedStatement and EmbedCallableStatement). We should do something similar on the client driver.

Issue Links

• is part of: DERBY-4582 Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).