JBM 1.4 has its own database schema. Considering using bridge to import your existing data to JBM.
What I meant with schema is the database schema you can normally set via the orm.xml.
Thus I could hang the JBM stuff not into it's own database but could add it as an other db schema to an existing database.
Are we talking about the same thing?
I have no issues with importing the data.
Slony just requires one complete replication system *per database*.
So the less databases I have, the better. (I am down to just one + JBM atm)
I'm not sure I understand you completely. I don't know Slony. But as long as JBM is concerned, one DB instance is enough for each JBM server, or each JBM cluster (where all nodes in one cluster share one DB instance).
If your replication system have access to the same DB, make sure their table names don't clash with JBM's.
Slony only does master-slave replication.
DBs A (master) and B (slave)
AppServer cluster with both A and B in their datasource list.
So in the normal case all cluster nodes connects to A (alas a shared database).
Slony externally replicates the database from A to B.
Now if A fails, the AppServers switch to B.
(the replication terminates in the background).
Question is, do I even need to replicate the JBM database to the slave?
As I have no idea how JBM persists it's data, I am unsure of this.
F.i. do the pre-failover messages still exist after failover if they were not replicated?
i.e. these messages are lost and would cause the subscribers to miss them.
If I do, then I wonder if it is possible to tell JBM to persist it's tables in a specific schema of the database in order to simplify the replication.
Thanks for clarification. In that case you need to replicate all the JBM tables from A to B. JBM doesn't have the facility to help.