ok. i think i start to see the problem. in case of a join, if 2 tx start around the same time, they both see each other still being active. then both of them will wait in the join. the parent will then not be propagated. both tokens will only update themselves so there will be no hibernate optimistic locking problem detected. afaict, the current implementation will operate correctly with isolation levels TRANSACTION_REPEATABLE_READ and TRANSACTION_SERIALIZABLE, which are highly uncommon. the solution would be to modify the parent token each time a token enters a join. then modifications to the parent will cause concurrent updates to be detected. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972533#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...