Camunda's database on production

186 views
Skip to first unread message

Facundo Farias

unread,
Feb 26, 2015, 3:33:30 AM2/26/15
to camunda-...@googlegroups.com
Hello there!
As I mentioned before, I am quite new with camunda (version 7.2) by using the java API embedded on out platform (and we are quite happy with it :D)

We are going live, with the first version, so I have some questions to do:

1. Would it be better to maintain different databases, one for camunda and another one for my application? (let's say, process-engine it's the camunda database, and my-app it's my application database). Or, you think it might be better to keep all the data mixed up in only one database? (I am not sure, but I guess that you have a preferred use by design, keeping in mind updates/upgrades of the platform and so on).

2. I've found some settings that I am not sure if I understand correctly (on the ProcessEngineConfiguration class):

2.1 The constant DB_SCHEMA_UPDATE_FALSE, will check the library database with the one on the database schema, and if they are different it will throw an exception.

2.2 The constant DB_SCHEMA_UPDATE_CREATE_DROP, it's meant mainly for development and will drop the schema once camunda it's stopped (not sure what is being closed means, as the javadocs said).

2.3 The constant DB_SCHEMA_UPDATE_TRUE, will update the schema to the latest changes. This is the preferred setting for production.

Am I right or am I missing something? Are the assumptions that I am doing for DEV/PROD are correct?

Thanks a lot in advance,

Facundo.

PS: Posting it in here, in order to see if I have better luck :/

Christian Lipphardt

unread,
Feb 26, 2015, 5:08:55 AM2/26/15
to camunda-...@googlegroups.com
Hi Facundo,

Awesome that your are happy with Camunda. We always like to hear this!

Regarding your questions:

1. Most of the time it is a question of separation of concerns where to store the application data. I advice to use your own database for it.

2.1 Yes, that's correct. It will check if any of the main engine tables are missing and then will throw an error.

2.2 DB_SCHEMA_UPDATE_CREATE_DROP or DB_SCHEMA_UPDATE_DROP_CREATE are meant for development use.

2.3 Here, you are mislead. The constant DB_SCHEMA_UPDATE_TRUE will only create missing database tables, it will NOT alter any existing database tables from the engine. For example it will not add any new columns to ACT_RU_JOB when the table already exists. Database updates/migration between Camunda BPM versions, see [1], must be performed manually using the supplied database base upgrade scripts packaged inside the different application server distributions at [2].

Cheers,
Christian

[1]: http://docs.camunda.org/latest/guides/migration-guide/
[2]: http://camunda.org/download/

Daniel Meyer

unread,
Feb 26, 2015, 5:11:16 AM2/26/15
to camunda-...@googlegroups.com
Note that  if you use a seperate databae for process engine and application tables you need to configure JTA / XA in order to have consistent commit / rollback of transactions which touch both process engine and application tables.



daniel
Reply all
Reply to author
Forward
0 new messages