Optimistic locking is based on the optimistic scenario that there will be very minimal chance of someone else changing the same set of data while another user is making changes to it, so in essence the initial data is allowed to be processed by two or more than two users simultaneously and at the time of committing it is checked that the initial set of data from which we started is same or not, if it is same no issues else, the data is reloaded from the new source of truth and then users current changes are discarded and he/she has to start afresh.
Pessimistic locking on the other hand does not allow anyone else to start making changes to the same set of data if someone else has already started and hence taken a lock on it.
For optimistic locking In BPM you can rely on the database to give you a version number for the initial set of data and check before submitting that the current version number is same as what you started with otherwise discard current changes and load the latest set of data.
For pessismistic locking the database issues a lock and we can check upfront if a lock exists or not and give the user appropriate message.
Another approach is to use shared business objects without relying on the db to give you a version number, version numbers and previous versions of the shared business objects can be loaded with api calls.