JBPM 6 开发者指南 Chapter 8.docxVIP

Chapter 8. Implementing Persistence and TransactionsIn real-life scenarios, we need to have process instances running for many hours, days, or even years. If we want to be able to run processes for such a long time, we cannot rely on something as volatile as the memory of a server to keep track of all our process instances statuses. We need a way to provide persistence for them.This chapter focuses on providing a persistence and transaction mechanism to our process engine environment, which will allow us to store enough information about our executions to be able to recreate them afterwards. This feature brings the possibility of having more than one thread or server trying to access the same persisted runtime environment at the same time. So, we will also learn how to generate a transaction around said persistence to make sure no concurrency issues occur.Persistence and transactions are topics that are hard to handle for newcomers, mostly because they entail a lot of different configuration points that need to be carefully orchestrated to get the expected behavior from our application. Once you have finished this chapter, you will learn about the following:How the jBPM6 persistence worksHow to configure all the different components of the persistence and transaction Why we need transactions in our systemsWhy do we need persistence and transactions?So far, we’ve dealt with very short-lived processes. Running inside a JUnit test, process instances last very few milliseconds, and having them in memory is sufficient for those environments. However, in real-life situations, we don’t usually create interactions between systems and humans without having long wait states in between. This is especially relevant for the case of processes with human tasks, where users backed up with too much work might have a pending task assigned to them for hours, days, or even more. For each of the processes in your environment, you should be able to determine whether it should be a persis