Thanks a lot Rob. I will be definitely using it.
Rawad On 30 Nov 2016 17:13, "Rob Godfrey" <rob.j.godf...@gmail.com> wrote: > 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 <rawad.as...@gmail.com> wrote: > > > 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. > > >
