Control the id generation for BpmProcessInstance

[brunobuzzi]

When a new BpmProcessInstance is created control if the id already exist.
The probability of an id clash is pretty high with 100.000 instances with ids up to 4294967295 (32 bit number).
Note:
theorically it could be a clash of [id] in collection IF for the same [BpmProcessDefinition] the random generation answer the same number [id := Lag1MwcRandom new integer].
Lag1MwcRandom new integer - answer a nonnegative 32bit integer. (max 4.294.967.295)
The probability of a clash depends on the number of [BpmProcessInstances]:
It can be calculated with (it take to much time to calculate):

|max instances p m |
max := 4294967295.
instances := 100000.
m := 1.
1 to: instances - 1 do: [:k | m := m * (1 - (k/max))].
p := 1 - m.
p asFloat.

A more efficient way is:

| numbers instances clashes |
numbers := Set new.
instances := 900000.
1 to: instances do: [:each | numbers add: Lag1MwcRandom new integer  ].
clashes := instances - numbers size.
clashes

With 100000 is pretty possible to have a clash --> a new issue to control the clash of ids should be created.

[brunobuzzi]

Check:
http://forum.world.st/Cost-of-includesKey-in-RcKeyValueDictionary-td5112509.html

[brunobuzzi]

The issue is partially fixed. But there is still a problem in:

BpmProcessDefinition>>addProcessInstance:
   processInstancesSet add: aBpmProcessInstance.
   ^processInstances at: aBpmProcessInstance id put: aBpmProcessInstance

If two different Gems (transactions) at the same time are adding a process it could be possible that both transactions generate the same id (let's call it clashID) and for both transactions processInstances at: classID is a free slot.

This is a border case because both process must have identical process definition and both transaction must overlap during the commit. In practical terms is highly unlikely but theorically possible. It will depend on how many process are been created per millisecond.

[brunobuzzi]

It seems if processInstances collection is an RC collection then replay is done and the entry will be overwritten unless the transaction that has the commit conflict do an abort.
Research on Seaside Web and Seaside REST what is done when a commit conflict with RC collection arise.