Question 21 :
Why should I consider optimistic versus pessimistic approaches to database updates?
In a modern database, possibly the two most important issues are data integrity and concurrency ( multiple users have access to and can update the data ). Either approach can be appropriate, depending on the application, but it is important to be aware of possible consequences to avoid being blindsided.
A pessimistic approach, with locks, is usually seen as good for data integrity, although it can be bad for concurrency, especially the longer a lock is held. In particular, it guarantees against 'lost updates' - defined as an update performed by one process between the time of access and update by another process, which overwrites the interim update. However, other users are blocked from updating the data and possibly reading it as well if the read access also tries to acquire a lock. A notorious problem can arise when a user accesses data for update and then doesn't act on it for a period of time. Another situation that occurred with one of my clients is that a batch ( non-interactive ) process may need to update data while an interactive user has an update lock on the same data. In that case, data integrity goes out the window and, depending on how the application is written, more problems may be introduced. ( No, we did not write the interactive update program and yes, we had recovery procedures in place. )
An optimstic approach can alleviate lock concurrency problems, but requires more code and care for integrity. The "optimistic" definition usually says that expectations of update clashes are rare, but I view them as normal occurrances in a heavily used database. The basics are that any changes between time of access and time of update must be detected and taken into account. This is often done by comparing timestamps, but one must be sure that the timestamp is always changed for an update and, of course, that the table contains a timestamp column. A more involved, but more complete method involves saving the original columns and using them in the 'Where' clause of the Update statement. If the update fails, the data has changed and the latest data should be reaccessed.
Question 22 :
What is optimistic concurrency?
An optimistic approach dispenses with locks ( except during the actual update ) and usually involves comparison of timestamps, or generations of data to ensure that data hasn't changed between access and update times. It's generally explained that the term optimistic is used because the expectation is that a clash between multiple updates to the same data will seldom occur.
Question 23 :
What is pessimistic concurrency?
With a pessimistic approach, locks are used to ensure that no users, other than the one who holds the lock, can update data. It's generally explained that the term pessimistic is used because the expectation is that many users will try to update the same data, so one is pessimistic that an update will be able to complete properly. Locks may be acquired, depending on the DBMS vendor, automatically via the selected Isolation Level. Some vendors also implement 'Select... for Update', which explicitly acquires a lock.
Question 24 :
Can I get information about a ResultSet's associated Statement and Connection in a method without having or adding specific arguments for the Statement and Connection?
Yes. Use ResultSet.getStatement(). From the resulting Statement you can use Statement.getConnection().
Question 25 :
How can I tell if my JDBC driver normalizes java.sql.Date and java.sql.Time objects?
To actually determine the values, the objects must be converted to a java.util.Date and examined. See What does normalization mean for java.sql.Date and java.sql.Time? for the definition of normalization. Notice that even a debugger will not show whether these objects have been normalized, since the getXXX methods in java.sql.Date for time elements and in java.sql.Time for date elements throw an exception.
So, while a java.sql.Date may show 2001-07-26, it's normalized only if the java.util.Date value is:
Thu Jul 26 00:00:00 EDT 2001
and while a java.sql.Time may show 14:01:00, it's normalized only if the java.util.Date value is:
Thu Jan 01 14:01:00 EST 1970