code: public List<Long> getProcessInstancesWaitingForEvent(String type) {
      	EntityManager entityManager = getEntityManager();
      	if (entityManager != null) {
  	        Query processInstancesForEvent = getEntityManager().createNamedQuery( "ProcessInstancesWaitingForEvent" );
  	        processInstancesForEvent.setParameter( "type",
  	                                               type );
  	        return (List<Long>) processInstancesForEvent.getResultList();
      	} else {
      		// entity manager can be null when fireActivationCreated is
      		// called on session unmarshalling
      		return new ArrayList<Long>();
      	}
      }
docs: This method is used by the {@link JPASignalManager} in order to load {@link ProcessInstance} instances
  into the {@link ProcessInstanceManager} cache so that they can then be signalled.
  </p>
  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.
  </p>
  Because the {@link org.drools.core.command.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
  <a href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Phantom_reads">phantom read</a>
  race condition, that might be caused by a lack of pessimistic locking on this query, isn't possible.
  </p>
  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.
  </p>