qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rawad Assaf <rawad.as...@gmail.com>
Subject Re: [java-broker] JDBCMessageStore
Date Wed, 30 Nov 2016 19:38:34 GMT
Thanks a lot Rob.

I will be definitely using it.

Rawad

On 30 Nov 2016 17:13, "Rob Godfrey" <rob.j.godfrey@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.assaf@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.godfrey@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 <keith.wall@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.wall@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.assaf@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message