One option might be to have the store plugin be able to add a prefix to the table names so that while they were all within the same schema, the tables containing the data for the different instances would be distinct - that is probably an easier change to make than trying to keep all the for all the brokers in the same tables - would that potentially be a solution for you?
-- Rob On 30 November 2016 at 10:54, ASSAF Rawad <[email protected]> wrote: > 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. >
