Chapter 5. Transactions, concurrency, and caching
This chapter covers
- Database transactions and locking
- Long-running conversations
- The NHibernate first- and second-level caches
- The caching system in practice with CaveatEmptor
Now that you understand the basics of object/relational mapping with NHibernate, let’s take a closer look at one of the core issues in database application design: transaction management. In this chapter, we examine how you use NHibernate to manage transactions, how concurrency is handled, and how caching is related to both aspects. Let’s look at our example application.
Some application functionality requires that several different things be done together. For example, when an auction finishes, the CaveatEmptor application has to perform four tasks:
- Mark the winning (highest amount) bid.
- Charge the seller the cost of the auction.
- Charge the successful bidder the price of the winning bid.
- Notify the seller and the successful bidder.
What happens if you can’t bill the auction costs because of a failure in the external credit card system? Your business requirements may state that either all listed actions must succeed or none must succeed. If so, you call these steps collectively a transaction or a unit of work. If only one step fails, the whole unit of work must fail. We say that the transaction is atomic: several operations are grouped together as a single indivisible unit.