Transactions in action
It's time to stop talking about transactions and isolation levels and finally see them in action. Open two different instances of the CalendarFrame application.
Make sure both application instances are set to See
only saved data, which corresponds to the TRANSACTION_READ_COMMITTED
isolation level.
In the first window, pick a day and add an event. Then go to the second window and display the events for that day. After a pause, you should get a dialog box (see Figure 10) telling you that the application can't retrieve the data because it's locked.
Figure 10. When you can't get a lock on the data
Now, in the first window, click the Save button to commit the transaction. Go back to the second window and try to refresh the page, but only once (see Figure 11).
Figure 11. Committing the transaction
Notice that you can now request the same data that was previously locked.
In the previous example, you saw how the database kept one user from
seeing uncommitted data for another user. But what if you don't want that
to happen? In both windows, set the isolation level to See all data.
Now add a new record in the first window, but don't save your changes. Go to the second window and display the events for that date. You should see all the events for that date, including the one you just entered a moment ago (see Figure 12).
Figure 12. Seeing dirty data
Now users can complete all their event-management tasks, including seeing what other users are up to.

