I think some things are mixed up here: the concurrencypredicate factory is meant to produce predicates (so, filters) on save to make an update fail if the predicate resolves to false. I.o.w.: the factory itself doesn't do anything other than producing a predicate which defines when the update fails or succeeds. It can't change state, the update statement does.
So the way to implement it is: the update which has a predicate which resolves to true, will succeed, the others will fail.
One could do this by adding a field which is your lock value. You set that field to a value, X (e.g a GUID), if it's NULL, which means the code which set the field is also owning the lock. Then execute an update which has an extra predicate which tests whether the extra field has the value X. No other code has that lock value, and all updates will fail.
Pessimistic locks are meant to make code wait. So the code which wants to set the value of the extra field to its own lock value and which is faced with failing updates because the value is already set (so the row is 'locked') has to wait till it succeeds.
In the end, it IMHO doesn't really matter what you use: in general whatever you choose makes one keep its work and the other one lose its work, unless you merge the two, or you avoid the one who would lose his/her work not start the work in the first place.