I guess my question here is what the benefit to sharing a schema is? You can already have multiple brokers running against the same Oracle installation as long as they are using different schemas... If they use the same schema would we be expecting the instances to store their data in the same tables? If so what would happen when a new version of Qpid comes out that updates the table structures? At the moment the upgrade process converts all the data in the tables into any new table structure, but how would that wrk if there were data from multiple Qpid installations in there? Sharing tables would also seem to potentially cause more contention between instances that would not occur if the data for different instance is held separately,
-- Rob On 30 November 2016 at 08:32, Keith W <[email protected]> wrote: > Hi Rawad > > Your analysis of the code is correct, currently the JDBCMessageStore > feature assumes exclusive use of the a schema. This is really a > reflection of the way this store module evolved - out of the Derby > store. It probably would not be too hard to change the code so that > sharing a schema becomes possible, but it is not something on the road > map for the near future. If the feature would be useful to you, feel > free to submit a patch. > > Kind regards, Keith Wall. > > > > On 29 November 2016 at 16:19, Rawad Assaf <[email protected]> wrote: > > Hi, > > > > I am trying to use a JDBC message store to persist messages of the > default > > virtualhost on an Oracle RDBMS. > > > > Looking at the SQL statements used (as per > > https://github.com/apache/qpid-java/blob/trunk/broker- > core/src/main/java/org/apache/qpid/server/store/ > AbstractJDBCMessageStore.java) > > it doesn't look as if I can persist messages from multiple brokers in the > > same Database Instance. > > > > Is this really the case? If yes, are there any plans to add such a > feature > > in future? It would be really practical not to have to create a separate > > Database Instance for each broker. > > > > > > Best regards, > > Rawad. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
