Overview | Package | Class | Use | Tree | Deprecated | Index | Help
| jBPM :: Distribution 6.2.0.Final
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## 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
`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
`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`

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
| jBPM :: Distribution 6.2.0.Final
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2001-2015 JBoss by Red Hat. All Rights Reserved.