org.jbpm.persistence

## Class JpaProcessPersistenceContext

- java.lang.Object
- - org.drools.persistence.jpa.JpaPersistenceContext
  - - org.jbpm.persistence.JpaProcessPersistenceContext

- All Implemented Interfaces:
    org.drools.persistence.PersistenceContext, ProcessPersistenceContext

      public class JpaProcessPersistenceContext
      extends org.drools.persistence.jpa.JpaPersistenceContext
      implements ProcessPersistenceContext

- - ### Field Summary

    - ### Fields inherited from class org.drools.persistence.jpa.JpaPersistenceContext

      `isJTA, pessimisticLocking, txm`

  - ### Constructor Summary

    Constructors
    Constructor and Description
    `JpaProcessPersistenceContext(javax.persistence.EntityManager em, boolean useJTA, boolean locking, org.drools.persistence.TransactionManager txm)`
    `JpaProcessPersistenceContext(javax.persistence.EntityManager em, org.drools.persistence.TransactionManager txm)`

  - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `ProcessInstanceInfo` | `findProcessInstanceInfo(Long processId)`
    `Long` | `getProcessInstanceByCorrelationKey(org.kie.internal.process.CorrelationKey correlationKey)` With regards to locking, the method is not always called during a transaction, which means that including logic to lock the query will cause exceptions and is not feasible.
    `List<Long>` | `getProcessInstancesWaitingForEvent(String type)` This method is used by the `JPASignalManager` in order to load `ProcessInstance` instances into the `ProcessInstanceManager` cache so that they can then be signalled.
    `CorrelationKeyInfo` | `persist(CorrelationKeyInfo correlationKeyInfo)`
    `ProcessInstanceInfo` | `persist(ProcessInstanceInfo processInstanceInfo)`
    `void` | `remove(ProcessInstanceInfo processInstanceInfo)`

    - ### Methods inherited from class org.drools.persistence.jpa.JpaPersistenceContext

      `close, findSessionInfo, findWorkItemInfo, getEntityManager, isOpen, joinTransaction, lock, lock, merge, persist, persist, remove, remove`

    - ### Methods inherited from class java.lang.Object

      `clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

    - ### Methods inherited from interface org.drools.persistence.PersistenceContext

      `close, findSessionInfo, findWorkItemInfo, isOpen, joinTransaction, lock, merge, persist, persist, remove, remove`

- - ### Constructor Detail

    - #### JpaProcessPersistenceContext

          public JpaProcessPersistenceContext(javax.persistence.EntityManager em,
                                      org.drools.persistence.TransactionManager txm)

    - #### JpaProcessPersistenceContext

          public JpaProcessPersistenceContext(javax.persistence.EntityManager em,
                                      boolean useJTA,
                                      boolean locking,
                                      org.drools.persistence.TransactionManager txm)

  - ### Method Detail

    - #### persist

          public ProcessInstanceInfo persist(ProcessInstanceInfo processInstanceInfo)

      Specified by:
        `persist` in interface `ProcessPersistenceContext`

    - #### findProcessInstanceInfo

          public ProcessInstanceInfo findProcessInstanceInfo(Long processId)

      Specified by:
        `findProcessInstanceInfo` in interface `ProcessPersistenceContext`

    - #### remove

          public void remove(ProcessInstanceInfo processInstanceInfo)

      Specified by:
        `remove` in interface `ProcessPersistenceContext`

    - #### getProcessInstancesWaitingForEvent

          public List<Long> getProcessInstancesWaitingForEvent(String type)

      This method is used by the `JPASignalManager` in order to load `ProcessInstance` instances into the `ProcessInstanceManager` cache so that they can then be signalled. Unfortunately, with regards to locking, the method is not always called during a transaction, which means that including logic to lock the query will cause exceptions and is not feasible. Because the `SingleSessionCommandService` design is based around a synchronized execute(...) method, it's not possible for one thread to create a process instance while another thread simultaneously tries to signal it. That means that a phantom read race condition, that might be caused by a lack of pessimistic locking on this query, isn't possible. Of course, if you're using multiple ksessions to simultaneoulsy interact with the same process instance, all bets are off. This however is true for almost everything involving process instances, so that it's not worth discussing.
      Specified by:
        `getProcessInstancesWaitingForEvent` in interface `ProcessPersistenceContext`

    - #### persist

          public CorrelationKeyInfo persist(CorrelationKeyInfo correlationKeyInfo)

      Specified by:
        `persist` in interface `ProcessPersistenceContext`

    - #### getProcessInstanceByCorrelationKey

          public Long getProcessInstanceByCorrelationKey(org.kie.internal.process.CorrelationKey correlationKey)

      With regards to locking, the method is not always called during a transaction, which means that including logic to lock the query will cause exceptions and is not feasible. However, this is not an issue: see the `getProcessInstancesWaitingForEvent(String)` documentation for more information. The same logic applies to this method.
      Specified by:
        `getProcessInstanceByCorrelationKey` in interface `ProcessPersistenceContext`

Copyright © 2001–2015 JBoss by Red Hat. All rights reserved.