Jorge Ferreira [http://community.jboss.org/people/imjorge] replied to the discussion "Multiple JBPM4_VARIABLE records pointing to same LOB_ and different EXECUTIONID_" To view the discussion, visit: http://community.jboss.org/message/549542#549542 -------------------------------------------------------------- We have found the cause of the problem. Basically jBPM was reusing the same block of identifiers as can be seen by the following two log lines: 73099 2010-06-24 16:40:54,018 DEBUG [org.jbpm.pvm.internal.id.DatabaseDbidGenerator] acquired new id block [2610001-2620000] 75993 2010-06-24 17:22:05,254 DEBUG [org.jbpm.pvm.internal.id.DatabaseDbidGenerator] acquired new id block [2610001-2620000] That caused all sort of strange behavior. Now why is this happing? First let me talk about our environment setup. We use jBPM as part of an EAR application deployed in jBOSS. Because we did not want to manage different databases we deployed the jBPM tables in our application database. So a single database with both application tables and jBPM tables. The problem happens with very specific conditions, as one could expected, and is due to the nature of http://en.wikipedia.org/wiki/Nested_transaction nested transactions. DatabaseDbIdGenerator picks a new block of ids inside a transaction. But because this can happen from an EJB call it will be a nested transaction. The problem only happens if the block generation happens in a nested transaction and the outer transaction - that would commit definitely the results of the nested transaction - rollbacks for some reason. 1. start transaction1. start jbpm transaction for block generation1. get current nextid from jbpm4_property - nextid = 1 2. update nextid in jbpm4_property - nextid = 100001 2. commit jbpm transaction 3. [...] 4. some error that causes an exception that means rollback 2. rollback transaction - nextid = 1 Because the ultimate result will be to rollback the transaction the block that jBPM THINKS that is on the database is now incorrect. But it still holds that block in memory and uses it to assign ids. The next time a block generation happens the ids will start to be repeated. Perhaps a check SHOULD be added in DatabaseDbIdGenerator to ensure that the nextId returned from the database is after the lastId consumed? *Our solution:* implement a custom id generator that uses an independent transaction and hook it up using jbpm.default.cfg.xml. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/549542#549542] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]