Package de.xima.fc.workflow.processor.logic.execution

Class FormRecordLockManager

  • @Deprecated
public final class FormRecordLockManager
extends Object
    Deprecated.
    form records are locked via Vorgang.isInArbeit(). In a future release the lock date of the FormRecordLock may return in one way or another.

    A Lock that allows locking a Vorgang for exclusive use. Used for example by the workflow processing engine.

    This is achieved via the Vorgang.isInArbeit() attribute. Locking uses the following SQL statement to ensure that only one thread can acquire the lock: 

     update form_record set flag_in_progress = true where id = ID and flag_in_progress = false;
    The lock is acquire successfully when the above statement returns an update count of 1. When two threads attempt to acquire the lock at the same time, only one of these statements can succeed with an update count of 1, assuming the database does not let queries access a temporary state from another transaction.

    Please note that the UPDATE statement used to acquire the lock is a so-called JPQL Bulk Update statement. According to the JPQL language reference, the "persistence context is not synchronized with the result of the bulk update or delete." (10.2.9. JPQL Bulk Update and Delete ) This means that even after successfully locking a Vorgang instance, the Vorgang.setInArbeit(boolean) flag WILL NOT be true, not even after rereading the Vorgang from the persistence context, such as via IVorgangDao#read(IEntityContext, Long). To quote the spec again:

    In general, bulk update and delete operations [and thus, form record lock operations] should only be performed within a separate transaction or at the beginning of a transaction (before entities have been accessed whose state might be affected by such operations).
    Since:
    7.0.0
    Author:
    XIMA MEDIA GmbH