If flowable.use-lock-for-database-schema-update=true is set during the first time the server is started, it will fail with the below error.
Failed to acquire lock appDbSchemaLock due to unknown exception
Looking further through the stack, the underlying issue is:
Cause: org.postgresql.util.PSQLException: ERROR: relation "act_ge_property" does not exist
This makes perfect sense, the lock can’t be stored in a table that doesn’t exist yet. However, this raises a question.
When running in a multi-node environment, to allow the DB schema to be created, is the expectation that flowable.use-lock-for-database-schema-update be set to false and only a single node started for the initial service startup? It appears that only after the initial schema exists can flowable.use-lock-for-database-schema-update=true be used to prevent multiple nodes from attempting to execute schema updates.
Your understanding is correct. This is expected behavior, not a defect.
When flowable.use-lock-for-database-schema-update=true, Flowable acquires the schema lock before it creates or updates the schema, and that lock is stored in a Flowable table. On a completely empty database that table does not exist yet, so the very first schema creation cannot store the lock — which is exactly the relation "act_ge_property" does not exist error you traced. (Note that what you observe as the failure is the lock acquisition eventually giving up after the wait timeout, which defaults to 5 minutes, rather than failing instantly.)
The lock is therefore designed to coordinate schema updates once the schema already exists; it is not meant to bootstrap the schema onto an empty database. So in a multi-node setup you need the schema to exist first, then enable the lock for ongoing concurrent updates. You have two good options for the initial bootstrap:
Create the schema with a single node first (your approach). Start one node with flowable.use-lock-for-database-schema-update=false so it creates the schema, then enable flowable.use-lock-for-database-schema-update=true for all nodes going forward. This is the simplest path and matches what you described.
Pre-create the schema out of band before any node starts. Flowable publishes per-database SQL scripts that create the full schema. Run those against the database first (this is also the route to use when the application’s database user does not have DDL privileges), then start all nodes with the lock enabled from the start. This avoids the “one special first boot” step entirely.
Once the schema exists, keeping flowable.use-lock-for-database-schema-update=true on all nodes is the right setting to prevent multiple nodes from running concurrent schema updates (for example during a version upgrade). The related tuning properties are flowable.lock-poll-rate (default PT10S) and flowable.schema-lock-wait-time (default PT5M).
For reference, the schema-update lock and these properties are described in the clustering section of the Flowable documentation, and the database SQL scripts / flowable.database-schema-update behavior are covered in the database section: https://documentation.flowable.com.
Best regards
Note: This Answer is AI generated and manually reviewed.