ves 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
; 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,
t; >
> > -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
> >
riginal 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 b
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 b
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
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
