Encountering Conflicting Changes in the Rental Swing Client

In order to see conflicting changes with the rental Swing client, you need a JDO implementation that uses a multiuser datastore. Most relational databases and object-oriented databases satisfy this requirement.

Start up two rental Swing clients. Identify Jim as the customer using the first client and Mary as the customer using the second client. Using Figure 9-3 as your guide, have Jim make his reservation and view Both. Have Mary make a nonconflicting reservation and view Both. Figure 9-3 shows the situation for the two client programs. As you can see, each has a reservation that does not conflict with the other, and each is able to modify only his or her own reservation.

Figure 9-3: Jim and Mary with nonconflicting reservations

Note

The rental Swing application uses optimistic JDO transactions to keep a transaction open at all times. Optimistic transactions are the appropriate choice for long-running transactions. It also sets the RetainValues property to true to improve performance by caching persistent state across transactions. All other transactional properties are set to false. To examine the properties used, look up the implementation's properties file in the com/ysoft/jdo/book/rental/local subdirectory under the bookcode-home directory.

Next, have Jim alter his reservation. For the dates shown in Figure 9-3, he cancels for October 5 and makes a reservation for October 12. He confirms and his change is accepted. He again selects Both from the View menu. Mary, on the other hand, is unaware of Jim's changes. She cancels her reservation for September 28 and makes a reservation for October 12. She confirms, but encounters an error condition that states "Concurrent changes by other users prevent your changes, try again."

After dismissing the error dialog box, Mary once again views her own reservations and the available rentals. Figure 9-4 shows her view of her own reservations and available reservations.

Figure 9-4: Mary's view after optimistic transaction failure

There are several points to notice in Figure 9-4. Although Mary cleared her reservation for September 28 before she attempted to confirm her changes, she now sees her reservation checked again. Her change has been undone because the RestoreValues property of the JDO Transaction is set to false. As a result, dirty objects were automatically evicted when the transaction rolled back. When the rental Swing client repaints the screen, new data reflecting the state in the datastore is loaded. For the same reason, Mary now sees that someone else has taken the reservation for October 12. Finally, although Jim has successfully cancelled his reservation for October 5, Mary's client shows this reservation as taken. Because Mary's Rental object for October 5 indicated, correctly at the time, that the rental was taken, she was not permitted to alter this reservation in her unsuccessful transaction. It remained persistent-nontransactional, and as a result, the transaction's rollback did not cause JDO to discard its persistent state. Mary must click the Refresh button to see that the rental for October 5 is now available. This behavior, when an optimistic transaction fails, satisfies use case 11.