You cannot do this. Every API-call has it's own command-context. At the end, the changes to the entities are flushed. Most of the times, transactions is also committed right after that, unless participating in an existing container-managed transaction.
If you add "async" to an activity, all progress up until that point will be saved to the database, job will be queued and transaction will be committed BEFORE control is returned to calling thread that did the API-call, causing the process to flow to that activity.
This is just how it works. You can't persists state in the DB unless activiti is certain that is consistent and can be continued at a later point in time (eg. after task complete, after timer fire, …) - exactly the reason why we don't allow forcing commits to the DB.
What is the usecase for this?