code: @Override
      public void startWorkflow( long woinRefNum ){
          log.debug( "Starting" );
  
          TransactionStatus status = null;
          try{
              workflowInstanceService.markStarting( woinRefNum );
              status = begin();
  
              WorkflowInstance woin = workflowInstanceService.find( woinRefNum );
              Environment env = Marshaller.deserializeEnv( woin.getAttributes() );
              GraphInstance graphInstance = engineFactory.getSingletonInstance().start( woin.getWorkflowName(), woin.getWorkflowVersion(), env, woinRefNum );
              graphInstanceRepository.save( graphInstance, WorkflowInstanceStatus.EXECUTED );
  
              commit( status, "Started" );
          }
          catch( UnexpectedStatusException e ){
              // See above for a reasoning on why these exceptions are caught separately.
              log.warn( e.getMessage() );
              if( status != null ){
                  rollback( status );
              }
              workflowInstanceService.unlock( woinRefNum );
              log.warn( "Unlocked", e );
          }
          catch( Exception e ){
              log.warn( "Handling error", e );
              rollback( status );
              try{
                  workflowInstanceService.handleStartingError( woinRefNum, e );
              }
              catch( Exception e2 ){
                  log.error( "Handling error failed.", e2 );
              }
              exceptionNotificationService.handleException( e );
          }
      }
docs: /*
  A few words on the treatment of UnexpectedStatusException's.
  
  In general, these exception should only occur as consequence of a
  concurrent status transition. A concurrent status transition may be
  caused by a user requesting a process to abort. For that reason, the
  given database changes are rolled rolled back and the process execution
  is unlocked (so that it may be polled for the aborting logic). No entry
  is added to the error logging tables.