You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Rawad Assaf <ra...@gmail.com> on 2016/11/29 16:19:31 UTC
[java-broker] JDBCMessageStore
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.
Re: [java-broker] JDBCMessageStore
Posted by Rawad Assaf <ra...@gmail.com>.
Thanks a lot Rob.
I will be definitely using it.
Rawad
On 30 Nov 2016 17:13, "Rob Godfrey" <ro...@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 <ra...@gmail.com> wrote:
>
> > That option would indeed be a solution.
> >
> > Thanks!
> > Rawad
> >
> > On Wed, Nov 30, 2016 at 1:01 PM, Rob Godfrey <ro...@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.NICOLASASSAF@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.godfrey@gmail.com]
> > > > Sent: Wednesday, November 30, 2016 10:42 AM
> > > > To: users@qpid.apache.org; Keith Wall <ke...@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 <ke...@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 <ra...@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-unsubscribe@qpid.apache.org For
> > > > > additional commands, e-mail: users-help@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.
> >
>
Re: [java-broker] JDBCMessageStore
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ra...@gmail.com> wrote:
> That option would indeed be a solution.
>
> Thanks!
> Rawad
>
> On Wed, Nov 30, 2016 at 1:01 PM, Rob Godfrey <ro...@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 <Ra...@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.godfrey@gmail.com]
> > > Sent: Wednesday, November 30, 2016 10:42 AM
> > > To: users@qpid.apache.org; Keith Wall <ke...@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 <ke...@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 <ra...@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-unsubscribe@qpid.apache.org For
> > > > additional commands, e-mail: users-help@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.
>
Re: [java-broker] JDBCMessageStore
Posted by Rawad Assaf <ra...@gmail.com>.
That option would indeed be a solution.
Thanks!
Rawad
On Wed, Nov 30, 2016 at 1:01 PM, Rob Godfrey <ro...@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 <Ra...@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.godfrey@gmail.com]
> > Sent: Wednesday, November 30, 2016 10:42 AM
> > To: users@qpid.apache.org; Keith Wall <ke...@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 <ke...@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 <ra...@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-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@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.
Re: [java-broker] JDBCMessageStore
Posted by Rob Godfrey <ro...@gmail.com>.
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 <Ra...@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.godfrey@gmail.com]
> Sent: Wednesday, November 30, 2016 10:42 AM
> To: users@qpid.apache.org; Keith Wall <ke...@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 <ke...@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 <ra...@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-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@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.
>
RE: [java-broker] JDBCMessageStore
Posted by ASSAF Rawad <Ra...@murex.com>.
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.godfrey@gmail.com]
Sent: Wednesday, November 30, 2016 10:42 AM
To: users@qpid.apache.org; Keith Wall <ke...@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 <ke...@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 <ra...@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-unsubscribe@qpid.apache.org For
> additional commands, e-mail: users-help@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.
Re: [java-broker] JDBCMessageStore
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ke...@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 <ra...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [java-broker] JDBCMessageStore
Posted by Keith W <ke...@gmail.com>.
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 <ra...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org