Hello, @Keith: Thanks for the confirmation. I might indeed get back to you with a patch for this.
@Rob: Your remarks/questions are very accurate. Our deployed solution uses multiple broker instances but they all have the same version and are upgraded at the same time. So we don't really have the risk you are highlighting although I understand that this might be problematic for a different use case. Having a single schema holding all the messages of all the brokers' virtualhosts simplifies the administrative operations. Creating a schema requires rights that we don't always have (it involves creating a user and assigning privileges, ...). If we hot-deploy a new broker instance it is simpler to connect it to an existing schema and not having to create a separate schema. Having said this, I agree that the performance might be negatively due to the contention on the shared schema. Best regards, Rawad -----Original Message----- From: Rob Godfrey [mailto:[email protected]] Sent: Wednesday, November 30, 2016 10:42 AM To: [email protected]; Keith Wall <[email protected]> Subject: Re: [java-broker] JDBCMessageStore 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] > > ******************************* This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.
