OK - I've made a change on trunk which should allow you to do this - on each JDBC virtual host / virtual host node you can set a "tableNamePrefix" so that multiple instances can share the same schema : QPID-7558 <https://issues.apache.org/jira/browse/QPID-7558>
-- Rob On 30 November 2016 at 13:09, Rawad Assaf <[email protected]> wrote: > That option would indeed be a solution. > > Thanks! > Rawad > > On Wed, Nov 30, 2016 at 1:01 PM, Rob Godfrey <[email protected]> > wrote: > > > 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. > > > > > > > > > -- > Rawad. >
