That option would indeed be a solution. Thanks! Rawad
On Wed, Nov 30, 2016 at 1:01 PM, Rob Godfrey <rob.j.godf...@gmail.com> 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 <rawad.nicolasas...@murex.com> > 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:rob.j.godf...@gmail.com] > > Sent: Wednesday, November 30, 2016 10:42 AM > > To: users@qpid.apache.org; Keith Wall <keith.w...@gmail.com> > > 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 <keith.w...@gmail.com> 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 <rawad.as...@gmail.com> > 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: users-unsubscr...@qpid.apache.org For > > > additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > ******************************* > > > > 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.
